Pillar 2 of 4
Find the cookie set before the consent banner showed up
We load your page in a clean browser, capture every cookie set in the first 2.5 seconds, and tell you which ones are tracking users without consent.
The pre-consent problem regulators care about
GDPR and ePrivacy require that any non-essential cookie or tracker is blocked until the user actively opts in. A surprising number of sites get this wrong because their tag manager fires Google Analytics or Meta Pixel before the consent banner has rendered. Even with a Cookiebot or OneTrust banner installed, the underlying scripts are often loaded with the page rather than gated behind the consent decision. We simulate a fresh visitor with no prior consent state. Anything in the cookie jar after page load — that isn't strictly necessary — is a finding.
Security flags that quietly fail in production
Modern browsers reject cookies with SameSite=None unless the Secure flag is present. We flag these because they break silently — your auth might appear to work locally and fail for a percentage of users in the wild. Long-expiry cookies (over a year) are a soft GDPR signal: regulators have written guidance suggesting cookie lifetimes should be proportionate to purpose, and 13 months is the de-facto retention cap most DPAs accept.
Classification you can trust
Every cookie name is checked against an exact-match dictionary first, then a prefix list (so _ga_XXXX inherits Google Analytics's classification). Cookies we can't classify get a minor severity finding so a human can confirm them — better to surface the unknown than to silently call it 'necessary'.
Example findings
Pre-consent tracking detected
Cookie "_fbp" (Meta Pixel, marketing) was set before the user gave consent. The cookie was issued 1.2 seconds after page load, while the consent banner was still mounting. To resolve, gate the Meta Pixel script behind your consent management platform's "marketing" toggle.
Cookie : _fbp Domain : .example.com Category : marketing Set at : t=1.2s (banner not yet interacted with) Expiry : 90 days
SameSite=None without Secure flag
Session cookie "sid" is set with SameSite=None but no Secure flag. Modern Chromium and Firefox silently reject this combination, so a percentage of your users — anyone with browser updates from the past three years — will lose state intermittently. Local development hides the issue because localhost is treated as Secure.
Set-Cookie: sid=abc123; Path=/; SameSite=None; HttpOnly Fix: add Secure flag and ensure the cookie is only set over HTTPS: Set-Cookie: sid=abc123; Path=/; SameSite=None; Secure; HttpOnly
Cookie expiry exceeds 13 months
Cookie "_ga" (Google Analytics, analytics) is set with a 24-month expiry. Most EU data protection authorities have published guidance treating 13 months as the de-facto maximum for analytics cookies, citing ePrivacy proportionality. A regulator audit would flag this as excessive retention.
Cookie : _ga Expiry : 24 months (730 days) DPA cap : 13 months (CNIL, ICO, AEPD) Fix: in your GA4 admin, set "Data retention" to 14 months or less, or self-host with a custom expiry.
Scan your site in 60 seconds
25 free credits. No credit card. Real findings on the page you care about.