Cookie Parser
Read Cookie request headers and Set-Cookie response fields without losing duplicate names, raw values, attributes, or browser-facing warnings.
A request Cookie header carries stored name-value pairs back to a matching site.
0 lines
Parsed Cookie Data
Raw values stay visible so convenience diagnostics do not silently rewrite the source.
Parsed cookie values, attributes, duplicate names, security summary, and diagnostics will appear here.
Cookies can contain live account credentials
Session cookies can sometimes be enough to access an account. Parsing stays in your browser and no cookie-parsing API receives the pasted text, but screenshots, copied output, or shared logs can still expose secrets. Site-wide analytics or advertising scripts, if enabled, are separate from this parsing operation.
Reading a Cookie Header Without Guessing
Cookie headers look simple because most of them are short, but they can represent several different things at once: a login session, language choice, shopping-cart identifier, experiment assignment, analytics state, or some application-specific value. The first useful question is not “what is a cookie?” but “what is this browser actually sending or being asked to store?”
If you copied a line from browser developer tools, first identify its direction. A server sends Set-Cookie in a response when it wants the browser to create or update a cookie. On a later matching request, the browser can send stored name-value pairs back in the Cookie request header. Those two headers are related, but they do not contain the same information.
A Quick Walkthrough
This request says the browser is sending three stored cookies. It does not tell you when those cookies were created, whether they were marked HttpOnly, when they expire, or which Domain and Path originally scoped them. Those policy attributes are not repeated in the Cookie request header.
This response is different: the server is asking the browser to store a cookie and is attaching policy information. That is where Secure, HttpOnly, SameSite, Domain, Path, Max-Age, Expires, and newer attributes appear.
What the Main Set-Cookie Attributes Actually Change
Secure restricts sending to secure transport. It is especially important for session cookies because a login token should not normally travel over an unencrypted HTTP connection.
HttpOnly prevents ordinary page JavaScript from reading the cookie through APIs such as document.cookie. The browser can still send that cookie with matching HTTP requests.
SameSite affects cross-site sending. Strict, Lax, and None change when the cookie can accompany cross-site navigations or requests. SameSite=None requires Secure in modern browsers.
Domain and Path determine where the browser considers the cookie applicable. They are matching rules, not a general security boundary.
Max-Age and Expires control lifetime. When both are understood, Max-Age takes precedence.
Duplicate Cookie Names Can Be Legitimate
The same cookie name can exist with different Path or Domain scope, so a request can contain more than one pair with the same name. Converting everything straight into a normal object can silently overwrite one value with another.
Keeping every occurrence and its order matters here. HTTP/2 and HTTP/3 can even split a request Cookie field across multiple field lines for compression and define recombination with ; ; that does not make comma-combining multiple response Set-Cookie fields safe. The HTTP/2 rule is spelled out in RFC 9113. If an application appears to read the “wrong” cookie, inspect what the browser actually stores, which Domain and Path each cookie uses, and how the server framework resolves duplicate names.
Why Cookie Values Sometimes Look Encoded
Applications often place encoded text inside cookie values. You may see percent sequences, Base64, JWT-like strings, opaque random identifiers, or framework-specific serialization. The Cookie grammar itself does not say that every value should be URL-decoded.
For that reason, the raw value remains the source of truth. If a value such as Sneha%20Pune can be percent-decoded cleanly, a readable preview can sit beside it without pretending that percent decoding is part of cookie semantics.
Why fetch() May Not Expose Set-Cookie
Frontend JavaScript cannot read Set-Cookie from a Fetch or XMLHttpRequest response the way it can read ordinary response fields. Browsers filter it from responses exposed to page code. Cross-origin requests also need the right credentials mode before a returned Set-Cookie field can affect the cookie store.
That distinction explains a common debugging puzzle: the network panel can show a Set-Cookie field while response.headers.get("set-cookie") does not reveal it. The browser behavior is documented alongside the Set-Cookie header rules.
Cookie Prefixes Add Browser-Enforced Restrictions
Supporting browsers attach additional rules to names beginning with __Secure-, __Host-, __Http-, and __Host-Http-. A __Host- cookie, for example, requires Secure, must use Path=/, and must not include Domain.
These prefixes reduce some dangerous scoping choices, but the header alone cannot prove that the response came from the secure origin required for the prefix. Current browser behavior for these prefixes and the Partitioned attribute is documented in the Set-Cookie reference on MDN.
When Login Works Once but the Session Disappears
- Confirm that the login response actually contains the expected Set-Cookie line.
- Check Secure, SameSite, Domain, Path, Max-Age, and Expires against the environment where the site runs.
- Use browser storage tools to see whether the browser accepted the cookie.
- On the next matching request, verify that the Cookie request header contains the expected value.
- If the cookie is present but the user is still logged out, investigate server-side session lookup, expiry, signature validation, revocation, or key rotation.
Secure + HttpOnly Does Not Mean the Whole Application Is Secure
Cookie attributes reduce particular risks, but they do not replace secure session design. Session identifiers still need strong randomness, safe expiry and revocation, fixation defenses, appropriate CSRF protection, and application-level protection against XSS and account takeover. A pasted header contains only the cookie metadata that is visible there; it says nothing about the authentication system behind it.
Header Syntax Cannot Predict Browser Acceptance
A Set-Cookie line can look structurally correct and still be rejected by a browser. Real acceptance can depend on the response origin, HTTPS, public-suffix rules, third-party-cookie policy, partitioning support, browser limits, current cookie-store state, and feature support. Core Cookie and Set-Cookie syntax is defined by RFC 6265, while newer browser behavior continues to evolve beyond that original RFC.