HTTP Cookie Parser
Paste a Cookie: request header or a Set-Cookie: response header and see each cookie's name, value, attributes, and warnings.
Name
session_id
Value
abc123def456
Name
theme
Value
dark
Name
locale
Value
ko-KR
Cookie names and values are URL-encoded in practice — the tool shows them as-is.
How to use
- Pick the direction: Cookie (request) or Set-Cookie (response).
- Paste one or more cookies. For Set-Cookie, put one cookie per line.
- Read off the per-cookie cards. Warnings appear on cookies the browser would reject or treat oddly.
About this tool
ShowHide
Two modes: Cookie: (what the browser sends — just name=value pairs) and Set-Cookie: (what the server returns — name, value, and attributes like Path, Domain, Max-Age, Expires, SameSite, Secure, HttpOnly, Partitioned). The parser flags common misconfigurations: SameSite=None without Secure, __Secure- cookies missing Secure, and __Host- cookies that don't pass the strict requirements.
The two directions carry different amounts of information, and the asymmetry catches people out. A Set-Cookie: line is a full instruction with every attribute attached, but the Cookie: header the browser sends back is only names and values. Nothing in it says which cookie was HttpOnly, which was scoped to a subdomain, or when any of them expires. If you are debugging why a cookie is missing, the request header cannot tell you; you need the Set-Cookie: that created it.
The __Host- prefix is the strictest guarantee available and the one worth reaching for. It requires Secure, forbids Domain entirely, and demands Path=/, which together mean the cookie belongs to exactly one host and no subdomain or sibling can have written it. __Secure- only requires Secure, so it says the cookie arrived over HTTPS and nothing about who set it.
Cookie scope is not the same as an origin, which is the gap most security surprises fall through. Cookies ignore the port, so a service on :3000 shares them with one on :8080 on the same host. They largely ignore the scheme too, so a cookie set over plain HTTP is readable over HTTPS on that host unless Secure is present. And a Domain=example.com cookie is visible to every subdomain, which makes any one of them able to overwrite it.
When both are present Max-Age wins over Expires, and Expires is interpreted against the client's clock, so a wrong device clock expires cookies early or keeps them past their date.
Frequently asked questions
Why is SameSite=None; Secure required?
Modern browsers refuse cross-site cookies without Secure since Chrome 80 — if you want third-party-context cookies to be sent, the cookie must travel over HTTPS. The tool flags SameSite=None without Secure so you catch it before deploying.
What's a __Host- cookie?
Cookies whose name starts with __Host- are subject to stricter rules: the cookie must have Secure, must not have a Domain attribute, and must have Path=/. This makes them strongly host-scoped — convenient for first-party authentication.
Why are multiple lines needed for Set-Cookie?
An HTTP response can carry multiple Set-Cookie headers, but they can't be merged onto one line because each cookie's value can legitimately contain a comma (e.g. in dates). The tool follows that convention: one cookie per line.
Why does the request header carry so much less than the response header set?
Because a browser sends back only names and values. Every attribute — expiry, path, domain, SameSite, HttpOnly, Secure — is an instruction to the browser about when to send the cookie, not data for the server, so it exists in Set-Cookie and never in Cookie. If you need an attribute's value on the server later, put it in the cookie's value or keep it in your own store.
Two cookies have the same name. Which one is mine?
You cannot tell from the header, which is the awkward part: a request lists name-value pairs with no path or domain attached, so a cookie set on a subdomain or a narrower path arrives looking identical to yours. The browser sends the more specific path first, but that is a convention rather than a guarantee. Prefix names to keep them distinct instead of relying on ordering.
Related tools
Cookie / Set-Cookie Header Builder
Compose a Set-Cookie header from name and value plus the security attributes — SameSite, Secure, HttpOnly, Partitioned, Max-Age — with safety warnings.
Network
HTTP Headers Reference
Searchable reference for ~50 standard HTTP request, response, CORS, caching, security, and cookie headers.
Developer
HTTP Basic Auth Encoder / Decoder
Encode username:password into the Base64 Authorization: Basic header — or paste an existing header back to see who's in it.
Network
Cache-Control Header Builder
Build an HTTP Cache-Control header from a visual checklist — freshness, revalidation, immutability, and the common presets.
Network
.gitattributes Tester
Paste a .gitattributes and a list of paths to see every attribute git ends up setting on each path, and which line — or which macro — set it.
Developer
JWT Decoder
Decode a JSON Web Token to inspect its header, claims, and expiration.
Developer