Cookie parser

Cookie: or Set-Cookie: · every attribute in a table · the rules browsers silently enforce

A cookie that "does not get set" is almost always a rule violation the browser applied without telling you: SameSite=None without Secure, a __Host- prefix with a Domain attribute, an Expires date already in the past. Paste the header and every attribute is laid out, with the violations named.

How to use

1. Paste either form. A Cookie: request header packs every cookie onto one line with no attributes; Set-Cookie: is one cookie per line with attributes. The tool works out which you pasted and says so in the summary.
2. Read the table. Percent-encoded values are shown both raw and decoded, since theme%3Ddark and theme=dark look very different when you are debugging.
3. Issues lists rule violations and risky configurations, each with what the browser will actually do about it.
4. The Summary totals the byte size — worth watching, because every cookie for a host is sent on every single request to it.

The rules browsers enforce without a warning

SameSite=None requires Secure. Without it the cookie is rejected outright — not downgraded, rejected. This is the most common cause of a third-party or cross-site cookie that never appears, and it produces no console error in most browsers.

No SameSite means Lax. Since 2020 an unspecified SameSite is treated as Lax, so the cookie is not sent on cross-site POSTs, iframes, or fetches. Code written before that change and never touched since often breaks in exactly one flow — usually a payment callback or an SSO POST — because that is the only cross-site POST in the app.

__Host- and __Secure- prefixes are enforced. A cookie named __Secure-x must have Secure. A cookie named __Host-x must have Secure, must have Path=/, and must have no Domain attribute at all. Break any of those and the browser drops the cookie silently. They are worth using — __Host- in particular makes a cookie impossible for a subdomain to overwrite, which defeats session-fixation via a compromised subdomain.

A leading dot in Domain does nothing. Domain=.example.com and Domain=example.com are identical to modern browsers: both include subdomains. Omitting Domain entirely is the restrictive option — a host-only cookie, which is what you usually want.

Expires in the past deletes the cookie. That is the standard way to remove one, so it is only a bug if you did not mean it. Max-Age takes precedence over Expires where both are present, and Max-Age=0 also deletes.

Size limits are real. A single cookie above roughly 4 096 bytes is dropped. Servers also cap total header size — nginx defaults to 8 KB for the whole request — so a large cookie jar produces a 400 Request Header Or Cookie Too Large that looks like a server fault.

Session cookies need HttpOnly and Secure. Without HttpOnly any injected script can read the session; without Secure it travels over plain HTTP. Cookies whose names look session-like are checked for both.

FAQ

Related URL tools