Cookie Analyzer

Runs in browser Validation

Paste one or many Set-Cookie headers to see each attribute explained, flagged issues (missing Secure/HttpOnly, SameSite=None without Secure, oversized cookies, __Host- prefix rules) and fixes.

Privacy: This tool runs entirely in your browser. Your input never leaves your device.

How do HTTP cookies work?

A cookie is a small name=value pair a server sets with the Set-Cookie header and the browser returns on later requests to the same site, which is how sessions survive between stateless HTTP requests. Its attributes decide its reach and safety: Expires/Max-Age (lifetime), Domain and Path (scope), Secure (HTTPS only), HttpOnly (hidden from JavaScript) and SameSite (cross-site sending).

Security note: A session cookie without Secure and HttpOnly can be stolen over plain HTTP or by injected script. Check the attributes on every authentication cookie, and that the session id changes after login.

How to use Cookie Analyzer

  1. Paste one Set-Cookie header per line (the "Set-Cookie:" prefix is optional) or a whole raw response.
  2. Results update live: the cookies table summarises attributes, lifetime and size.
  3. Work through the findings from high to low severity; each has a suggested fix.
  4. Copy the hardened headers and adjust HttpOnly for cookies that scripts must read.

Cookie Analyzer features

  • Parses any number of Set-Cookie headers, including a raw response or curl -i output
  • Explains every attribute: Secure, HttpOnly, SameSite, Domain, Path, Expires, Max-Age, Partitioned, Priority
  • Rules: SameSite=None requires Secure, __Host-/__Secure- prefix constraints, public-suffix domains, invalid dates, 400-day lifetime caps, 4096-byte size limit
  • Stricter checks for cookies that look like sessions, tokens or CSRF secrets
  • Per-cookie score and an overall score with severity-ranked findings
  • Hardened Set-Cookie headers generated for copy-paste

Cookie Analyzer example

A session cookie missing Secure

Input:

Set-Cookie: sessionId=a3f9c2e1b7d4; Path=/; HttpOnly

Output:

sessionId · Secure: no · HttpOnly: yes · SameSite: (default Lax) · Lifetime: session · Score: 55
High — Missing Secure: the cookie can be sent over plain HTTP and intercepted.
Medium — No SameSite attribute: set it explicitly.
Hardened: Set-Cookie: sessionId=a3f9c2e1b7d4; Path=/; Secure; HttpOnly; SameSite=Lax

Frequently asked questions about Cookie Analyzer

What are the __Host- and __Secure- prefixes?

__Secure- requires the Secure attribute; __Host- additionally forbids Domain and requires Path=/, binding the cookie to exactly one host. Browsers reject prefixed cookies that break these rules.

Why does SameSite=None require Secure?

Browsers drop SameSite=None cookies without Secure. None is only needed for legitimate cross-site use such as embedded widgets or third-party SSO.

How big can a cookie be?

About 4096 bytes per cookie including name, value and attributes; browsers also cap the number of cookies per domain. Keep session data server-side and store only an identifier.

What does the score mean?

100 minus penalties: 30 per high-severity finding and 15 per medium. Session or auth cookies are judged more strictly than preference cookies.

Can I paste a whole response?

Yes — the tool extracts every Set-Cookie header from a raw response or curl -i output. Nothing leaves your browser.

Technical notes

Parsing follows RFC 6265bis: the first name=value pair is the cookie, subsequent semicolon-separated tokens are attributes matched case-insensitively. Unknown attributes are reported because browsers silently ignore them — a common source of "why is SameSite not applied" bugs caused by typos.

When several Set-Cookie headers were joined by a proxy into one comma-separated value, the analyzer splits them again while keeping Expires dates (which contain commas) intact.

References