Cookie Parser: Decode Cookie and Set-Cookie Headers, With Validation
Cookie attributes interact in ways that are easy to get subtly wrong — a missing Secure flag silently breaks a SameSite=None cookie, a missing Path applies more narrowly than expected, and the __Host-/__Secure- name prefixes enforce rules that fail the whole cookie if violated. This tool parses both Cookie and Set-Cookie headers and flags the mistakes that actually cause cookies to be rejected or misapplied.
SameSite=None requires Secure. __Host- requires Secure, no Domain, and Path=/.
Why SameSite=None + Secure Is Non-Negotiable
Browsers enforce this pairing as a hard requirement, not a suggestion — a Set-Cookie header with SameSite=None but no Secure attribute is silently rejected entirely. This trips up developers testing locally over plain HTTP, where the cookie will simply never appear even though the header looks syntactically correct.
The __Host- and __Secure- Prefixes
These aren't just naming conventions — browsers actively enforce their requirements. A cookie named __Host-session that's missing Path=/ or includes a Domain attribute will be rejected outright. The prefixes exist specifically so a server can trust that a cookie with that name could only have been set under strict conditions, defending against certain cookie-injection attacks from subdomains or less-trusted contexts.
Path Defaults to the Setting URL's Path, Not /
A cookie set from a response to /api/login defaults to Path=/api if Path isn't explicitly specified — not the whole site. This is a common source of 'my cookie isn't showing up on other pages' bugs, fixed by explicitly setting Path=/ when the cookie should apply site-wide.
Practical Examples
Catching a Rejected Cross-Site Cookie
Missing the required Secure flag.
- 1.Set-Cookie: token=abc; SameSite=None
- 2.Warning: SameSite=None requires Secure
- 3.Fix: add Secure to the header
Validating a __Host- Cookie
Checking all three required conditions.
- 1.Set-Cookie: __Host-session=xyz; Secure; Path=/
- 2.Valid: Secure ✓, no Domain ✓, Path=/ ✓
What Gets Checked
- SameSite=None requires Secure
- __Secure- prefix requires Secure
- __Host- prefix requires Secure, no Domain, Path=/
- Redundant Expires + Max-Age
- Missing Path defaulting narrower than expected
Good Use Cases
- Debugging why a cookie isn't being set by the browser
- Reviewing a Set-Cookie header before shipping an auth flow
- Parsing a captured request's Cookie header for debugging
- Learning cookie attribute rules with concrete validation feedback
Frequently Asked Questions
What's the difference between a Cookie header and a Set-Cookie header?
Cookie is sent by the browser to the server on a request, containing just name=value pairs for every cookie that applies to the request. Set-Cookie is sent by the server to the browser on a response, and includes both the name/value and attributes (Domain, Path, Expires, Secure, etc.) that control how the browser should store it.
Why does SameSite=None require Secure?
Browsers enforce this as a security requirement — a cookie that's sent on cross-site requests (SameSite=None) but not restricted to HTTPS (Secure) would be exposed to network interception in a way browsers no longer allow. Modern browsers silently reject SameSite=None cookies that lack Secure.
What are the __Secure- and __Host- name prefixes?
These are cookie name prefixes that browsers enforce extra rules on. __Secure- requires the Secure attribute. __Host- requires Secure, no Domain attribute (locking the cookie to the exact host), and Path=/. They're a defense against certain cookie-injection attacks, since a script or attacker can't forge a cookie with these prefixes without also satisfying the stricter requirements.
What happens if both Expires and Max-Age are set?
Max-Age takes precedence in all modern browsers when both are present — Expires becomes a fallback only for very old browsers that don't support Max-Age, which by now is essentially none. Setting both is redundant but not harmful.
What does it mean if Path isn't set?
The cookie's path defaults to the path of the request URL that set it — not '/' as some assume. This can make a cookie set from /account/settings only apply to URLs under /account/, not the whole site, unless Path=/ is set explicitly.
Is my cookie data sent anywhere?
No, all parsing happens locally in your browser via string parsing — no upload, which matters since session cookies are sensitive data.