🍪 Cookie Inspector
Enter a URL to fetch every Set-Cookie header and analyze Secure / HttpOnly / SameSite / Domain / Path / Expires, prefixes, and size limits.
📚 Cookie Attribute Reference
• Secure: Sent only over HTTPS
• HttpOnly: Inaccessible to JavaScript (XSS protection)
• SameSite=Strict: Never sent on cross-site requests
• SameSite=Lax: Sent on top-level GET navigation only (default)
• SameSite=None: Sent cross-site (requires Secure)
• __Secure- prefix: Requires Secure flag
• __Host- prefix: Requires Secure + no Domain + Path=/ (strong isolation)
• Partitioned (CHIPS): Lives in a partitioned third-party context
📖 What this check tells you
This check connects to the URL you give it, parses the Set-Cookie headers that come back, and reports whether Secure, HttpOnly, SameSite and the rest are present. Cookies written later by JavaScript through document.cookie cannot be seen here. Analytics and ad tags almost always take that route, so the number actually stored in a browser is normally larger than what this page lists — check the Application tab in devtools for the full picture.
| Item | What it means | How to fix it |
|---|---|---|
| SameSite left unspecified | When it is absent, modern browsers treat it as Lax. A Lax cookie is sent only on top-level GET navigation — never on a cross-site POST, inside an iframe, or on fetch. The bug where the session vanishes the instant a payment provider POSTs the user back is almost always this. |
Always state it explicitly for the job at hand: SameSite=Lax for an ordinary session, Strict for an admin panel where CSRF resistance matters most, and SameSite=None; Secure for payment flows that POST back or for embedded use. None without Secure gets the cookie dropped entirely, so write them as a pair. |
| The Domain attribute is set | Counter-intuitively, Domain=example.com widens the scope rather than narrowing it. Omit it and the cookie goes only to that exact host; include it and it goes to every subdomain. If even one host such as user.example.com lets users publish content, the main session cookie is readable from there. |
The safest default is to leave Domain out and set it only where sharing is genuinely required, at the narrowest scope. To harden further, name the cookie with the __Host- prefix: the browser then enforces Secure, no Domain and Path=/, so a configuration slip cannot widen it. |
| Too many cookies, or too large | A single cookie holds about 4 KB and a domain holds roughly 50, beyond which the browser silently evicts the oldest. That is a surprisingly common explanation for hard-to-reproduce complaints like occasional logouts or a cart that sometimes empties. Cookies also ride along on every request to the domain, so they cost bandwidth even when fetching images and CSS. | Put only an identifier in the cookie and keep state on the server. Stuffing a whole JWT in easily passes 4 KB. Move non-auth preferences such as the display theme or a dismissed banner into localStorage so they stop travelling with every request, and serve static assets from a separate domain or CDN where no cookie applies. |
What the EU ePrivacy directive and comparable national rules require is that no cookie be written before consent is given, not that a banner be displayed. A setup where analytics tags issue Set-Cookie before anyone clicks accept may fail the requirement despite having a banner. Looking at the cookies returned the instant this check opens your home page gives you a first read on that. Technically and legally, the surest measure is simply to have fewer cookies.