Cookie Security Analyzer
Paste the cookies a site stored in your browser to see who sets each one and what it is for, or paste Set-Cookie headers to get every security issue with its severity, a fix and the exact RFC rule.
🔒 100% client-side — what you paste is read in this browser, never uploaded or stored. Cookie values can identify you: they are hidden by default and you can reveal each one.
Cookies a site stored: open the site, press F12, go to Console, type document.cookie and copy the result (cookies marked HttpOnly are not shown there). For all of them: Network → reload → click the page request → Request Headers → copy the Cookie: line.
Set-Cookie headers: the same request, Response Headers, or curl -sI https://example.com. One header per line; the Set-Cookie: prefix is optional.
How to use it
To find out what the cookies on a site are for, paste what the site stored in your browser (first hint above). Each cookie shows who sets it, what it is for and how long it lasts, taken from the vendor's own documentation, with a link to it. A cookie that is not on that list shows as not in the list: we do not guess. To review the security of your own site's cookies:
- Open your site in the browser, go to DevTools → Network, reload, click a request, and copy the
Set-Cookie:lines from Response Headers (or runcurl -sI https://example.com). - Paste them above, one header per line, and press Analyze (or click Try an example first).
- Read each cookie card: the observed attributes (what the header literally says) are separated from the findings (issues and advice).
- Apply the fix shown for each finding and re-paste the new header to confirm it is clean.
- Export the report (Markdown, JSON, CSV or TXT) for a ticket or audit trail.
What it checks (and the rule behind it)
- Browser rejection — the cookie is dropped by a modern browser:
SameSite=NonewithoutSecure; the__Secure-prefix withoutSecure; the__Host-prefix withoutSecure, withoutPath=/, or with aDomainattribute (RFC 6265bis §4.1.3, §5.4). - Security weaknesses — missing
Secure(sent over plaintext HTTP) or missingHttpOnly(readable by JavaScript, worse for session/auth cookies) (RFC 6265 §4.1.2.5–6). - Scope & defaults — no
SameSite(browsers default to Lax, but be explicit); an unrecognisedSameSitevalue; aDomainattribute that widens the cookie to all subdomains (a leading dot is ignored per RFC 6265 §5.2.3). - Lifetime & size —
Max-Age/Expiresbeyond the 400-day browser cap (6265bis §5.5), invalid or deleting lifetimes, and cookies larger than 4096 bytes (RFC 6265 §6.1).
How the grade is computed
No black box. Each finding adds demerit points — high = 40, medium = 15, low = 5, info = 0. A cookie’s grade comes from its total: A = 0, B ≤ 5, C ≤ 20, D ≤ 40, F > 40. The overall grade is the average across the cookies analysed.
Where the purposes come from
About a hundred common cookie names (analytics, advertising, consent tools, bot protection, login sessions of common platforms), each described from its vendor's own cookie documentation, linked on every card. A matching name is a strong hint, not proof: any site can reuse a name.
Limitations
A Cookie header or document.cookie only contains names and values, so security attributes can only be checked on Set-Cookie headers. This is a static review of the header text only. It cannot know the request URL, so it cannot verify that a cookie was actually set over HTTPS, derive the default Path, or evaluate the Public Suffix List for the Domain. The __Host-/__Secure- prefixes are also only enforced when the cookie is set from a secure origin — always test against the live browser. Time-relative Expires checks use your device clock.
Pair with the HTTP Security Headers Grader and the CSP Builder. To block tracking cookies in the first place, read Harden your web browser (part of the Privacy Guides); to strip tracking from links, use the Tracking Link Cleaner.