A Cookie to JSON converter takes a strict HTTP Cookie request header such as SID=abc; lang=en-US and turns it into a flat JSON object whose keys are cookie names and whose values are strings, then reverses that mapping into a serialized Cookie field. A working Cookie converter example for the input SID=abc; lang=en-US; cart=abc== produces a JSON object with three string members, preserving every character literally rather than URL-decoding percent sequences or normalizing separator spacing. The reverse example turns a reviewed JSON object such as {"preference":"dark","SID":"abc","cart":"abc=="} back into the exact field value preference=dark; SID=abc; cart=abc==, retaining JSON member order through a lexical scan and keeping the extra equals signs as value data. The strict serialization profile is what makes the example reproducible: every pair must be name=value, multiple pairs must be joined by exactly a semicolon and one ASCII space, and outer ASCII spaces around the pasted line are trimmed for convenience. Names follow the RFC token profile and remain case-sensitive, so SID and sid are two distinct keys. Values follow the RFC cookie-value profile as unquoted permitted cookie octets or the same sequence wrapped in double quotes, and percent sequences such as %2F stay as the three characters percent, two, and F. Set-Cookie response headers, which carry attributes such as Domain, Path, Expires, Secure, HttpOnly, and SameSite, are explicitly out of scope and produce an explicit error rather than misleading JSON. Try it on your own input through the Cookie to JSON Converter.
What a Cookie Converter Example Produces
Two example directions cover the realistic needs behind the keyword. The Cookie-to-JSON direction turns a serialized request header into a flat JSON object so each name and value can be reviewed, sorted, or moved into another tool. The JSON-to-Cookie direction takes a reviewed string map and produces a request-header value ready to drop into an HTTP request or a test fixture. Both directions return plain text in a read-only area and run entirely in the current tab without sending pasted material to a server, which matters when the cookie string contains a live session secret.
The output layout is the same shape as the most common debug workflow: a JSON object on one side of the example and the source or destination field on the other. The 100,000 UTF-16 code-unit input cap and the 200,000 code-unit output cap are exact, so the next code unit beyond either boundary is rejected. Conversion never slices, caps, samples, skips, or partially returns input, which means a successful example is the entire input and nothing more.
A Cookie-to-JSON Example Walked Through
Paste the following bare value into Cookie-to-JSON mode:
SID=abc; lang=en-US; cart=abc==
Three pairs are present. The first equals sign in each pair is the structural separator, and the third pair's abc== keeps its trailing equals signs as value data, which is exactly what signed tokens, query strings, and Base64 padding look like. After conversion, the read-only output area shows:
{ "SID": "abc", "lang": "en-US", "cart": "abc==" }The pair count is three, every value is a JSON string, and the indentation is two spaces because the internal forward map serializes through JSON.stringify with two-space indentation. The internal map is built with a null prototype so the result is a plain object, not an instance of Object.prototype, and the reserved names __proto__, prototype, and constructor are blocked in both directions as a defense-in-depth boundary.
Adding an exact field-name prefix is allowed. Pasting Cookie: SID=abc; lang=en-US produces the same JSON object, because the strict profile accepts the optional Cookie: prefix immediately followed by the value. COOKIE: works too, because field-name matching is case-insensitive. Cookie : does not work, because the space between the word and the colon is malformed.
A JSON-to-Cookie Example Walked Through
Switch to JSON-to-Cookie mode and paste:
{"preference":"dark","SID":"abc","cart":"abc=="}
The lexical scan reads one nonempty object whose decoded keys are RFC tokens and whose decoded values are cookie-octet strings. Member order is retained for output convenience, although Cookie semantics should not depend on serialization order. The result is:
preference=dark; SID=abc; cart=abc==
The separator between pairs is exactly a semicolon and one ASCII space. No percent-encoding is added, no quotes are added or removed, and no sorting is performed. The pair count is three, and the trailing == survives because only the first equals sign in each pair is structural. The reverse direction validates the decoded key as an RFC token and the decoded value as an accepted cookie-value, so escaped characters are decoded before that check; an escaped newline therefore fails because its decoded control character is not cookie-value data.
Run the Cookie Converter Example Locally
- Open the Cookie to JSON Converter and choose the Cookie-to-JSON direction.
- Paste a bare strict value such as SID=abc; lang=en-US; cart=abc==, or include the exact Cookie: prefix if you copied the field from a request capture. Add the field name only when you want to verify that the prefix parser accepts it.
- Click convert and review the read-only output, the pair count, and any error message. Editing input or switching direction clears the prior output, pair count, clipboard status, and clipboard timer, so the displayed result always reflects the current text.
- For JSON-to-Cookie, paste one nonempty JSON object whose decoded keys pass the token check and whose decoded values are accepted cookie strings, then click convert. The result is a single Cookie field value ready to paste into an HTTP client or a test fixture.
- Copy the complete output with the copy button. Clipboard writing is asynchronous and uses a generation identifier, so an older "Copied" state never restores after an edit, retry, direction change, or unmount. If the browser denies clipboard permission, the complete output remains visible for manual selection.
Inputs That Break a Cookie Converter Example
Acceptance and rejection scenarios are easier to compare side by side than to list in prose, so the table below pairs a representative input with the strict-profile outcome. Every accepted row maps cleanly to a Cookie-to-JSON output or a JSON-to-Cookie output, and every rejected row would surface a clear error rather than a normalized result.
| Scenario | Example input | Result |
|---|---|---|
| Bare strict header | SID=abc; lang=en-US | Accepted, produces flat JSON object |
| Optional prefix | Cookie: SID=abc; lang=en-US | Accepted, case-insensitive prefix match |
| Space around equals | SID = abc; lang=en-US | Rejected, strict profile forbids boundary spaces |
| Missing separator space | SID=abc;lang=en-US | Rejected, requires exactly ; |
| Trailing semicolon | SID=abc; lang=en-US; | Rejected, no trailing semicolon allowed |
| Duplicate name | SID=abc; SID=def | Rejected, no first-wins or last-wins behavior |
| Prototype-risk name | __proto__=x; a=1 | Rejected, defense-in-depth block |
| Set-Cookie prefix | Set-Cookie: SID=abc; Path=/ | Rejected, response attribute scope |
| JSON with number value | {"n":1} | Rejected, only string values allowed |
| Duplicate decoded JSON keys | {"a":"1","\u0061":"2"} | Rejected, lexical scan detects duplicates |
The strict rejection rather than silent normalization is the reason the example behaves the same on every run. A debugging workflow that tolerates malformed input would hide the very ambiguity that prompted the question.
Limits, Scope, and Safety Notes for the Example
The example is bounded on both sides. Input must be 100,000 UTF-16 code units or fewer, complete output must be 200,000 code units or fewer, and a zero or invalid output length is rejected. The interface never uses maxLength to silently cap typing, so the entire input reaches the parser and the entire accepted result reaches the output area.
The example never reads document.cookie, never modifies the browser cookie store, and never issues an HTTP request. Cookie headers frequently carry live session secrets, so treat the example like any other handling of credentialed text: keep pasted material private, and rotate any session token that has been exposed outside a trusted environment. For deeper rule detail, the Cookie Converter Cheat Sheet: Strict RFC 6265 Pairs walks the full profile.
Out of scope for the example: Set-Cookie response headers and their attributes, percent-decoding of any sequence, automatic quoting or unquoting, sorting, attribute inference such as Domain or Path, and any claim about whether a cookie is secure. The behavior described here is grounded in RFC 6265, and the converter does not invent behavior outside that profile. For general JSON work such as formatting or validating unrelated text, the JSON Formatter or JSON Validator will be a better fit, since those tools do not apply the Cookie profile at all.