Cookies arrive as dense header strings: a Cookie header lists name=value pairs separated by semicolons, while a Set-Cookie header adds attributes such as Path, Expires, Secure, and SameSite that control where the cookie goes and how long it lives. Debugging login problems, consent banners, and cross-site issues usually comes down to reading one of those strings correctly, and a missed attribute can change the whole diagnosis. This parser breaks a header into its cookies and attributes, one per line, so you can see exactly what the browser was told to store and under what rules.
Quick Answer: Paste a Cookie or Set-Cookie header and click Parse to see each cookie and its attributes.
Free Online Tool
Cookie Header Parser
Parse Cookie / Set-Cookie header strings into a readable attribute table.
How to Use the Cookie Header Parser
- Copy the Cookie or Set-Cookie header from your browser developer tools.
- Paste it into the input box.
- Click Parse.
- Read each cookie name and value on its own line.
- Read the attributes listed under each cookie.
- Check Path, Domain, and SameSite against the behaviour you expected.
Key Features
- Handles both Cookie request headers and Set-Cookie response headers.
- Separates cookie values from attributes correctly.
- Recognises Path, Domain, Expires, Max-Age, Secure, HttpOnly, and SameSite.
- Shows flags such as Secure and HttpOnly even without a value.
- Preserves values that contain equals signs.
- Runs entirely in the browser; nothing is sent anywhere.
What the Result Means
Each cookie line is one stored value; the attributes beneath it are the rules for that cookie. Path restricts the cookie to part of a site, Domain controls which hosts receive it, and Expires or Max-Age controls how long it lives. Secure means the cookie only travels over HTTPS, HttpOnly means JavaScript cannot read it, which limits theft via scripting, and SameSite controls whether it is sent on cross-site requests. A cookie that seems to vanish is usually explained by one of those attributes: the wrong Path, an expired Max-Age, or a SameSite rule that blocks it.
Worked Example
A user reports being logged out on one section of a site but not another. Parsing the Set-Cookie header shows session=abc123 with Path=/admin, which explains it exactly: the cookie is only sent for addresses under /admin, so the rest of the site never sees the session. The fix is to widen the Path to / when the session genuinely covers the whole site, or to keep the narrow Path deliberately when the admin area should have its own session. Widening the Path to / fixes the logout, and the parser makes the cause visible in seconds instead of an afternoon of guessing about the session store.
Best Practices and Tips
- When a login does not stick, check Path and Domain first; they are the usual culprits.
- Look for HttpOnly on session cookies: its absence is a security finding.
- Compare the Set-Cookie response with the Cookie request to see what the browser actually kept.
- Watch SameSite=None without Secure, which browsers now reject.
- Note expiry carefully: a session cookie with no Expires dies when the browser closes.
Common Mistakes to Avoid
- Reading a Set-Cookie string as if every segment were a separate cookie.
- Assuming a cookie without Secure is safe on an HTTPS site.
- Forgetting that Path defaults to the request path, not the whole site.
- Treating HttpOnly as encryption; it only blocks script access.
Frequently Asked Questions
What is the difference between Cookie and Set-Cookie?
Set-Cookie is the server telling the browser to store a cookie; Cookie is the browser sending stored cookies back.
What does SameSite do?
It controls whether a cookie is sent on cross-site requests, which defends against cross-site request forgery.
Why is my cookie not sent?
Usually because of Path, Domain, Secure, or SameSite rules, or because it expired.
Can JavaScript read HttpOnly cookies?
No. That is the point: HttpOnly cookies are hidden from scripts to limit theft.