HTTP Cookie Inspector: Parse and Debug Cookie Headers in Seconds

You paste a Set-Cookie header into your terminal output and see something like this:

session=abc123xyz; Domain=example.com; Path=/; Expires=Fri, 31 Dec 2027 23:59:59 GMT; Max-Age=63072000; HttpOnly; Secure; SameSite=Strict

Now what? You need to know if Secure is set, how long the cookie actually lasts, and whether SameSite is configured correctly. The manual approach — splitting on semicolons, googling attribute names, calculating expiry from a Unix timestamp — wastes five minutes every time. The HTTP Cookie Inspector does it in two seconds.

HTTP Cookie Inspector is a free, browser-based developer tool that parses both types of cookie headers:

Cookie (Request) — the header browsers send to servers, containing one or more name=value pairs
Set-Cookie (Response) — the header servers send to browsers to store a cookie, with the cookie value plus optional attributes

Paste the raw header value, and the tool breaks it down into a clean visual output: every attribute named and explained, security flags shown as colour-coded badges, expiry converted to human-readable relative time, and any missing security attributes flagged immediately.

No sign-up. No configuration. Runs entirely in your browser — your cookie strings never leave your machine.

HTTP cookies are deceptively simple to use and surprisingly easy to misconfigure. Here is what makes debugging them tedious:

Raw Header Strings Are Hard to Read

A Set-Cookie header with seven attributes is a 180-character semicolon-delimited string. Parsing it manually means splitting on semicolons, trimming whitespace, and matching attribute names case-insensitively — and then separately converting an RFC 1123 date string into something meaningful.

Missing Flags Are Silent Failures

If you forget Secure, the browser sends the cookie over HTTP — a silent security hole. If you forget HttpOnly, JavaScript can steal the cookie via XSS. If you set SameSite=None without Secure, modern browsers silently reject the cookie. None of these failures produce a visible error. Your session just breaks in production.

Expiry Is Confusing

Expires=Fri, 31 Dec 2027 23:59:59 GMT means nothing at a glance. Is that two years or six months? And if both Expires and Max-Age are set, which one wins? (Max-Age wins, per RFC 6265 — most developers don't know this.)

Use the tab toggle to choose your header type. For request headers (the Cookie: header), the tool parses every name=value pair and displays them in a clean table with one-click copy. For response headers (the Set-Cookie: header), it goes deeper.

Paste Your Header Value

Paste the raw value — just the part after Set-Cookie:, with no header name needed. Or click "Load example" to see the inspector working on a realistic production-style cookie string immediately.

See the Parsed Output

For Set-Cookie headers, the output shows:

Cookie Details table:

Name and value (with copy buttons)
Domain (or "not set — defaults to current host")
Path (or "not set — defaults to /")
Expiry: human-readable absolute date plus relative time ("in 1y 9mo")

Security Attributes badges:

HttpOnly, Secure, SameSite=Strict shown as green badges when present, struck-through when missing

Security Warnings:

Any missing or misconfigured attributes shown as a clear warning list

| Check | What It Means | |---|---| | Missing Secure | Cookie sent over HTTP — vulnerable to interception on non-HTTPS connections | | Missing HttpOnly | Accessible via document.cookie in JavaScript — at risk from XSS | | Missing SameSite | Browsers may apply different defaults; specify explicitly | | SameSite=None without Secure | Modern browsers reject this combination | | __Secure- prefix without Secure | Prefix contract violated — browsers silently reject | | __Host- prefix issues | Requires Secure flag, no Domain, and Path=/ |

A cookie that passes all checks shows a "No security issues found" confirmation instead of a warning list.

Auth Cookies Not Persisting

Your login sets a session cookie, but users get logged out as soon as they close the tab. Paste the Set-Cookie header from the login response. The inspector will immediately show if you have a session cookie (no Expires or Max-Age) when you intended a persistent one — or if Max-Age is set to a smaller value than Expires, which overrides it.

Cookies Not Sent on Cross-Origin Requests

Your API is on api.example.com and your frontend is on app.example.com. Cookies set on one domain are not automatically sent to the other. Paste your Set-Cookie header and check the Domain attribute. If it is missing or set incorrectly, the browser will scope it to the exact host that set it.

HTTPS Cookies Rejected in Development

You copied a production cookie to test locally over HTTP. The Secure flag prevents the cookie from being sent over non-HTTPS connections — so it simply does not work in your local environment. Paste the header, confirm Secure is the reason, and decide whether to modify the cookie for local development.

Parsing Multiple Cookies from a Request

A complex request sends 12 cookies in a single Cookie: header. Switch to Cookie mode, paste the full header string, and see every pair in a table. Copy individual values for debugging without manually splitting on semicolons.

What the Tool Does Not Do

HTTP Cookie Inspector is a static header parser. It does not:

Fetch cookies from live URLs (use your browser's DevTools Network tab for that)
Modify or create Set-Cookie headers
Test whether a server accepts a cookie
Show cookies currently stored in your browser

For live network inspection, your browser's DevTools Application tab is the right tool. The Cookie Inspector is for when you have a raw header string and need to understand it quickly.

Try It Now

Paste any Cookie or Set-Cookie header at http-cookie-inspector.tools.jagodana.com. No signup. No install. Your cookie strings stay in your browser.

If you find a missing security check or an attribute it does not handle, open an issue on GitHub.