A cookie converter cheat sheet condenses the strict serialization rules of HTTP Cookie request headers into a reference you can scan while debugging sessions, reviewing logs, or moving real cookie strings into JSON for tooling. The cheat sheet works because the Cookie request format is fully defined: pairs are written as name=value, multiple pairs are separated by exactly one semicolon followed by one ASCII space, and names use the RFC token profile. A strict local converter enforces those boundaries instead of silently normalizing malformed input, which makes it the right shape for a cheat sheet — every row represents an accepted or rejected input. The rows below cover the bare Cookie value, the optional Cookie: prefix, whitespace rules, percent sequences, base64-style padding, quoted values, empty values, and prototype-risk keys. Use the Cookie to JSON Converter alongside this cheat sheet when you need to confirm the precise behavior of a particular input.
Cookie Request Format Cheat Sheet
A strict Cookie-to-JSON converter checks four layers on every paste: the optional field-name prefix, the pair-level separator, the name and value syntax, and the duplicate-key rule. The table below lists the patterns developers paste most often, the verdict the strict converter returns, and the rule behind each verdict so you can predict the result before submitting the input.
| Input snippet | Verdict | Reason |
|---|---|---|
| SID=abc; lang=en-US | Accepted | Bare Cookie request value, two pairs, exact `; ` separator |
| Cookie: SID=abc; lang=en-US | Accepted | Exact Cookie: prefix, pairs follow strict serialization |
| COOKIE:SID=abc | Accepted | Field-name match is case-insensitive |
| Cookie : SID=abc | Rejected | Space between the name and the colon is malformed |
| SID=abc; lang=en-US | Accepted | Outer ASCII spaces around the line are ignored |
| SID = abc; lang=en | Rejected | Boundary space around the structural equals is not normalized |
| SID=abc;; lang=en | Rejected | Empty pair between separators is invalid |
| SID=abc;lang=en | Rejected | Missing single space after the separator semicolon |
| SID=abc; lang=en | Rejected | Two spaces after the separator are not normalized |
| SID=abc; | Rejected | Trailing semicolon with no following pair |
| =abc | Rejected | Empty name fails the RFC token profile |
| SID | Rejected | Pair with no structural equals sign |
| SID=abc; SID=def | Rejected | Duplicate name compared case-sensitively |
| Set-Cookie: SID=abc; lang=en | Rejected | Response header is not a Cookie request field |
| __proto__=x; a=1 | Rejected | Prototype-risk key blocked in both directions |
| constructor=x; a=1 | Rejected | Prototype-risk key blocked in both directions |
| token=%2Fpath; a=1 | Accepted | Percent sequence preserved literally, three characters kept |
| sig=abc==; a=1 | Accepted | Extra equals signs after the structural one remain value data |
| pref=; a=1 | Accepted | Empty value is a valid Cookie pair |
| pref="quoted"; a=1 | Accepted | DQUOTE-wrapped value, surrounding quotes are preserved |
Both directions share the same boundary checks. JSON-to-Cookie validates that input parses as exactly one nonempty JSON object, then applies the same RFC token rule to every decoded key and the same cookie-value rule to every decoded value. JSON escapes are decoded before Cookie validation, so a literal escape that resolves to a forbidden character is rejected — for example an escaped newline fails because the decoded control character is not cookie-value data. Duplicate decoded keys are detected before any serialization begins, so escaped spellings such as a and \u0061 are treated as the same key even though ordinary JSON.parse would silently keep only one.
Convert a Cookie Header in Three Steps
The strict converter runs only inside the current browser tab. Output is plain text in a read-only area, and nothing is sent to Lizely or any external service. Use it for debugging a Cookie request field, moving a reviewed string map into JSON, or producing a request-header value from reviewed JSON strings.
- Choose the Cookie to JSON direction and paste a strict bare Cookie request value such as SID=abc; lang=en-US, or include the exact Cookie: field-name prefix. The field-name match is case-insensitive (so COOKIE: also works), but Cookie : with a space before the colon is malformed and will be rejected. Outer ASCII spaces around the line are stripped for convenience.
- Or switch to the JSON to Cookie direction and provide exactly one nonempty JSON object whose decoded keys are RFC tokens and whose decoded values are JSON strings. Numbers, booleans, null, arrays, nested objects, comments, trailing commas, and any text after the closing brace are rejected. Decoded duplicates across escapes, including a and \u0061, fail before the join step runs.
- Convert, review every preserved string and the pair count, then copy the complete local output. Clipboard writing is asynchronous and each copy attempt carries a generation identifier, so an older permission response cannot restore the Copied state after an edit, retry, or direction change. Clipboard denial leaves the full output visible for manual selection rather than reporting a false success.
JSON-to-Cookie: Reverse Direction Rules
The reverse direction follows the same Cookie profile in reverse. Accepted pairs join with the exact separator `; ` (semicolon followed by a single ASCII space), the decoded key is revalidated as an RFC token, and the decoded value is revalidated as an accepted cookie-value. The converter does not percent-encode forbidden characters, add quotes automatically, strip quotes that the input carried, sort members, infer paths, or generate any Set-Cookie attribute. Member order is retained by the lexical pair scan for output convenience, but Cookie semantics should not depend on serialization order — a server can interpret cookie values using application-specific rules that this converter does not know.
Both directions block the prototype-risk keys __proto__, prototype, and constructor before serialization. The forward direction uses a null-prototype internal map with two-space JSON indentation, so those names never become own properties on the emitted object. The reverse direction rejects them before the join step, so the output Cookie value never carries them as a pair. Rejection happens even though JSON text can represent those strings and the internal forward map has no prototype — the boundary prevents downstream code from treating the generated output as a safe assignment source. The tool does not claim that arbitrary downstream JSON handling is secure, and consumers must still parse and merge untrusted data safely.
Why Set-Cookie Input Is Rejected
The converter handles Cookie request headers only. It does not parse Set-Cookie response headers, and it does not treat Domain, Path, Expires, Max-Age, Secure, HttpOnly, SameSite, Partitioned, Priority, or any other extension attribute as a request cookie. Those attributes are supplied by a server in Set-Cookie and are not returned by the browser in the Cookie request field. A Cookie header therefore cannot reveal a cookie's expiry, permitted hosts, permitted paths, secure-only state, or HttpOnly state. Pasting an exact Set-Cookie: prefix produces an explicit error instead of misleading JSON, Bare names without a value, such as HttpOnly, fail as pairs missing a structural equals sign, while syntactically valid name=value pairs such as Path=/ or Domain=example.com are accepted as ordinary Cookie request pairs because the converter does not treat attribute names specially.
The strict parsing profile this converter enforces comes from RFC 6265, the HTTP State Management Mechanism that defines the cookie name token profile, the cookie-octet value profile, and the request serialization format. The successor draft-ietf-httpbis-rfc6265bis refines those definitions around the same boundary the converter relies on, and the cheat sheet rows above track that boundary rather than any browser-specific normalization.
Limits and What the Converter Will Not Do
Input is limited to exactly 100,000 UTF-16 code units and complete output to 200,000 code units. Exact limits are accepted and the next unit is rejected, so the boundary is predictable. The interface does not use maxLength to silently block typing, and conversion never slices, caps, samples, skips, or partially returns input. A zero-length or invalid output length is rejected, so an empty conversion never appears as a success. Any error removes the previous successful result before publishing the message, and editing the input or switching direction clears the prior output, error banner, pair count, clipboard status, and clipboard timer.
| Task or question | Handled by this tool |
|---|---|
| Parse a strict Cookie request header into a flat JSON string map | Yes |
| Produce a strict Cookie request-header value from a flat JSON object of strings | Yes |
| Parse a Set-Cookie response header or recover its attributes | No — those attributes are not in the request field |
| URL-decode, percent-decode, or otherwise interpret percent sequences | No — the three literal characters are preserved |
| Reveal whether a cookie is Secure, HttpOnly, or session-scoped | No — the request field carries no such signal |
| Silently normalize malformed separator spacing or quoted pairs | No — strict rejection replaces normalization |
| Read document.cookie or modify the browser cookie store | No — nothing is read or written outside the pasted text |
| Transmit the pasted text off the device | No — both directions run entirely in the current tab |
| Use as a credential sanitizer before sharing | No — treat pasted text as already sensitive |
For general JSON work outside the strict Cookie profile, the JSON Formatter and JSON Validator cover readable formatting and pinpoint error locations, and the JSON Minifier produces a strict compact form without the cookie-rule surface.
Safety Notes for Working With Live Cookies
Cookie headers often contain live session secrets. Paste only what you intend to handle, treat copied output as confidential, and rotate any credential that has been exposed through screenshots, logs, or shared output. The converter writes to the clipboard asynchronously, and every copy attempt receives a generation identifier that a mounted-state guard enforces, so a permission response from an older prompt cannot restore the Copied state after an edit, direction change, retry, or unmount. Clipboard denial leaves the complete output visible for manual selection rather than reporting a false success, and copying is the only network-adjacent side effect of the page — there is no fetch, XHR, WebSocket, or postMessage call.
Editing the input or switching direction clears prior output, the error banner, pair count, clipboard status, and clipboard timer, so a stale result cannot be mistaken for a fresh conversion. The converter reads nothing from document.cookie, never modifies the browser cookie store, and never makes an HTTP request. Use it for debugging a Cookie request field, moving a reviewed string map into JSON, or producing a request-header value from reviewed JSON strings; do not use it to inspect browser storage, build Set-Cookie responses, preserve attributes, decode an application's session format, decide whether a cookie is secure, or sanitize credentials before sharing.