Cookie Viewer

Paste an HTTP cookie string and read it as a table instead of squinting at a one-line header. Choose the input type — a Set-Cookie response header, a Cookie request header, or a document.cookie value — and the viewer breaks out each cookie's name and value plus, for Set-Cookie, every attribute: Domain, Path, Expires, Max-Age, Secure, HttpOnly, SameSite, Priority, and Partitioned. It also flags common security problems, such as a session cookie missing HttpOnly or SameSite=None without Secure. Everything is parsed in your browser — nothing is uploaded.

How to use the Cookie Viewer

Copy the cookie text from wherever you have it — a browser DevTools network tab, a curl -i response, a server log, or the console output of document.cookie — and paste it in. Then pick the matching input type. Set-Cookie header parses a full response directive with all its attributes; paste one per line if a response sets several cookies. Cookie header and document.cookie string both parse the simpler request-side form, which is just name=value pairs separated by semicolons and carries no attributes.

For Set-Cookie input the viewer shows a table with the cookie name, value, and a column for each attribute it found, normalizing attribute names so secure, Secure, and SECURE all read the same. For request-side input it lists each name/value pair. Below the table, a notice highlights potential security issues: a cookie with SameSite=None but no Secure flag, a session-looking cookie (named like sid, session, or token) without HttpOnly, a cookie sent over an insecure context without Secure, and expirations set unusually far in the future. These are guidance, not verdicts: whether a given cookie needs a flag depends on what it does.

HTTP cookies: Set-Cookie, Cookie, and the security flags

Cookies are how a stateless protocol remembers you. HTTP has no built-in session, so a server stores a small piece of state in the browser and gets it back on later requests. The mechanism is two headers pointing in opposite directions. The server sends Set-Cookie in a response to create or update a cookie; the browser stores it and then echoes the relevant cookies back in a Cookie request header on every subsequent request to that site. The request-side Cookie header is deliberately plain — just name=value; name2=value2 — because all the policy lives in the original Set-Cookie. The document.cookie property exposes that same request-side view to JavaScript, minus any cookie marked HttpOnly.

The attributes on a Set-Cookie control scope and lifetime. Domain and Path decide which requests carry the cookie. Expires sets an absolute date and Max-Age sets a lifetime in seconds (and wins when both are present); without either, the cookie is a session cookie that dies when the browser closes. Priority hints at eviction order when storage is full, and Partitioned opts a cookie into CHIPS, which isolates it per top-level site.

Three flags are about security and deserve attention. Secure tells the browser to send the cookie only over HTTPS, so it cannot leak over plain HTTP. HttpOnly hides the cookie from JavaScript, which blunts cross-site scripting attacks that try to steal session tokens through document.cookie. SameSite governs cross-site sending: Strict withholds the cookie on any cross-site navigation, Lax (the modern default) sends it on top-level GET navigations but not on cross-site subresource requests, and None sends it everywhere but is only honored together with Secure. SameSite is also central to the industry-wide deprecation of third-party cookies: cookies set in a cross-site context are increasingly blocked by default, which is why analytics and ad systems are migrating away from them. Reading these attributes correctly is the difference between a cookie that protects a session and one that quietly exposes it.

Common use cases

• Debug a login. See exactly what attributes your auth Set-Cookie carries when a session won't stick.
• Security review. Spot session cookies missing HttpOnly or Secure, or SameSite=None set without Secure.
• Read a request header. Break a long Cookie header into a readable list of name/value pairs.
• Inspect document.cookie. Parse the console output of document.cookie to see what scripts can read.
• Verify SameSite behavior. Confirm a cookie's SameSite value before debugging cross-site request issues.