Cookie ⇄ JSON

Cookie parsing: the request header carries only key-value pairs, not the attributes

First, separate the two kinds of cookie string

This is the easiest point to confuse, because the two formats differ in shape, location, and purpose:

So the line you copy from browser dev tools, session=abc; theme=dark, will not contain HttpOnly, Secure, or SameSite. To confirm whether a cookie is HttpOnly, look at the response Set-Cookie header, or the cookie list in the Application or storage panel — those attributes never appear in the request header. This misunderstanding is common and leads to the puzzled question "why can't I parse out HttpOnly".

Encoding issues in the value

A cookie value has no mandated encoding rule, which is the practical source of trouble:

• Some frameworks URL-encode the value on write (producing %3D, %20, and so on) and decode on read; others do not. The same value therefore looks different across stacks.
• If a value contains a URL-encoding sequence but was meant to be literal (a JWT will not, but a base64 value may contain %), auto-decoding corrupts the data.
• How to tell: decode once and see whether the result becomes more meaningful (structural markers like {" or s: appear). If so, decode it; if decoding yields illegal characters, the original was literal.

Cookie values may not contain semicolons, commas, or whitespace — those are structure and separator characters. So a complex structure (JSON, an object) must be encoded or serialized before it goes in.

Common shapes of cookie content

The second row must be stressed: decodeable does not mean forgeable. A JWT's signature is protected by the server's key, and tampering is rejected. Do not assume a value is insecure just because "you can see the content", and do not assume it is secret just because "it looks encoded" — a JWT's payload is plaintext-readable.

Size and count limits

• About 4 KB per cookie (the total of name, value, and attributes). Beyond that the browser silently drops it — no error, the cookie simply stops appearing. Stuffing a large object into a cookie is a classic trap.
• About 50 cookies per domain (browsers vary slightly), evicted beyond that by policy.
• Every request carries its matching cookies, so the larger the cookie, the larger the per-request header overhead. Use cookies only for small data that genuinely must auto-attach on every request.

Two prefix conventions are worth knowing: __Secure- requires the Secure attribute, and __Host- requires Secure, no Domain, and Path=/. These prefixes let the browser reject unsafe writes for you — a defense against cookie poisoning.

How to use the tool

Paste a cookie string to parse it into a JSON object (semicolon and space separators, duplicate names, and empty values are all handled), or join an object back into a cookie string to paste into curl, a test case, or document.cookie.

Safety note: a production session cookie is equivalent to account credentials. Do not paste it into any online tool, including this one. This tool runs entirely locally and makes no requests, but credential data should be handled as a no-trace habit: use sanitized fake values while debugging, or process it with a local script.