Paste a raw HTTP cookie string — document.cookie, a Cookie: header value, or a curl -H "Cookie: ..." snippet — and parse it into a clean JSON object, a decoded name/value table, and validation with __Secure- / __Host- prefix checks. URL-decoding is automatic, quoted values are honored, and everything runs 100% in your browser. Need a full raw header block with Set-Cookie breakdown instead? Use our HTTP Headers Parser.
Parse a cookie string to JSON
Result
JSON object
Decoded table
Name
Raw value
Decoded value
Flags / notes
Validation
Nothing leaves your browser: parsing, decoding, and validation are pure client-side JavaScript — no fetch, no XHR, no storage.
Build a cookie string from JSON
Paste a JSON object and convert it back into a name=value; name2=value2 cookie string. Values are percent-encoded by default; nested objects become JSON strings.
Cookie string
(press Build)
Worked examples
Click Load on any example to run it through the parser above.
1. Session cookies (document.cookie style)
The classic name=value; name2=value2 string copied from DevTools → Application → Cookies.
sessionid=abc123; theme=dark; csrftoken=xyz789
2. URL-encoded values
Spaces, braces, and symbols arrive percent-encoded; the parser decodes John%20Doe → John Doe and even detects the JSON-encoded prefs value.
A browser sends cookies as a single Cookie request header: semicolon-separated name=value pairs, exactly what document.cookie returns in JavaScript. This tool converts that cookie string to a JSON object in one step: it strips an optional Cookie: prefix (or extracts the value from a curl -H flag), splits pairs while honoring double-quoted values, URL-decodes every value with a raw fallback, and reports duplicates, empty names, and invalid characters. The builder tab reverses the process, converting a JSON object back into a valid cookie string with optional percent-encoding.
Related tools: HTTP Headers Parser for full raw header blocks and Set-Cookie attribute breakdowns.
Frequently asked questions
They parse different things. The HTTP Headers Parser at /tools/http-headers-parser/ parses a full HTTP header block: the status or request line, every header, a Set-Cookie attribute breakdown (Path, Domain, Expires, Secure, HttpOnly, SameSite), and missing-security-header checks. This Cookie Parser is narrower and deeper on the request side: it takes the Cookie request string itself — document.cookie or the value of a Cookie: header, i.e. name=value pairs the browser sends — and turns it into a JSON object, a decoded table, validation, and cookie-prefix analysis. Use this tool when you already have the cookie string; use the headers tool when you have the whole raw header block.
RFC 6265 only allows a limited set of characters in a cookie value (cookie-octet). Spaces, semicolons, commas, quotes, and all non-ASCII characters must be percent-encoded by the application that sets the cookie — so user=John Doe is stored as user=John%20Doe and emoji as %F0%9F%98%80. The parser runs decodeURIComponent on every value automatically and shows both the raw and the decoded value side by side; the Raw toggle (or unchecking URL-decode) shows the string exactly as it arrived.
That is the entire point of the HttpOnly flag: it tells the browser to hide the cookie from JavaScript so that an XSS vulnerability cannot steal it. document.cookie only exposes cookies without HttpOnly, for the current domain and path. If a session cookie is missing from your parse, it is almost certainly HttpOnly (or set for a different path/domain) — check the Set-Cookie response in DevTools Network or your server logs instead. The parser flags session-looking names (sessionid, token, jwt, auth...) and reminds you of this.
Not directly — Set-Cookie has a different grammar (one cookie plus attributes like Path, Domain, Expires, Max-Age, Secure, HttpOnly, SameSite), while this tool expects the request-side Cookie string of plain name=value pairs. If you paste a Set-Cookie line, the attributes will show up as odd-looking pairs and the validator will flag them. For Set-Cookie breakdown and security-header checks, use the HTTP Headers Parser at /tools/http-headers-parser/.
The tool keeps every occurrence in the table in the order you pasted, flags each duplicate as a warning, and the JSON object keeps the last value — matching what common parser libraries do. The HTTP spec does not guarantee a meaningful order between duplicates, so no tool can tell you which one the server will honor; the reliable fix is to deduplicate the cookie names at the source.
They are opt-in security contracts from RFC 6265bis. A name starting with __Secure- is only accepted by browsers when the cookie was set with the Secure attribute over HTTPS; __Host- additionally requires Path=/ and forbids the Domain attribute, locking the cookie to the exact host. Servers that violate these rules get their Set-Cookie silently rejected. This tool detects both prefixes and explains the requirement for each, since a mysteriously 'missing' cookie is often a rejected prefixed cookie.
RFC 6265 allows a value wrapped in double quotes, and a semicolon inside those quotes does not separate pairs — cart="a;b" is one cookie, not two. The parser's splitter honors quoting, strips the outer quotes for the decoded value, keeps the raw form in the Raw column, and marks the row as quoted so you can see the transformation.
No. All parsing, decoding, validation, prefix detection, and JSON building run in JavaScript inside your browser. There is no upload, no API call, no fetch/XHR at all, and nothing is stored or logged. You can disconnect from the network after the page loads and the tool keeps working — which is exactly what you want when pasting session tokens.
We use cookies and third-party services (including Google AdSense) to personalize content, analyze traffic, and serve relevant ads. By clicking "Accept", you consent to our use of cookies as described in our Privacy Policy.
Report an issue
2 taps, no typing needed — diagnostics are sent automatically.