A Cookie request header is itself a bulk container: every name=value pair the browser sends to a host lives on a single line separated by exactly "; ", so a single conversion pass handles the whole set rather than one cookie at a time. The Cookie to JSON Converter is built around that single-line shape and the strict RFC 6265 request profile, which is what most developers mean when they search for a cookie converter bulk workflow. It turns one pasted header value, optionally prefixed with the field-name Cookie:, into a flat JSON object whose every key and value is a string, and it rebuilds that same header value from reviewed JSON in the opposite direction. Because the parser splits pairs only at the first equals sign in each pair, values that contain additional "=" characters such as Base64 padding, signed tokens, or query strings stay intact instead of being silently decoded or rewritten. Output is plain text in a read-only area, conversion runs entirely in the current browser tab, and nothing is sent to Lizely or any third party during the operation.
What "Bulk" Means in a Cookie Request Header
Browsers do not send one HTTP header per cookie. When a user agent returns state to a server, it packs every name=value pair for the host into a single Cookie request field, with each pair separated by exactly the two characters "; ". That is why a "bulk" cookie converter is really one strict parser applied to one line of text, and the Cookie to JSON Converter accepts the entire field in one paste, so two pairs or twenty pairs take the same effort.
A typical browser header might look like SID=abc; lang=en-US; cart=42 or include an explicit field-name prefix such as Cookie: SID=abc; lang=en-US; cart=42. Outer ASCII spaces around the line are trimmed for convenience, but the inner separator must remain ; byte for byte. If the field-name is present, Cookie must be followed immediately by a colon; Cookie : is malformed and rejected. Matching of the field-name itself is case-insensitive, so COOKIE:a=1 is accepted, while name matching inside the pairs remains case-sensitive, so SID and sid are two distinct keys. Empty values such as preference= are valid; an empty name or a pair without an equals fails.
How a Strict Cookie Converter Differs From a Lenient One
Many ad-hoc cookie parsers quietly fix malformed input. A trailing semicolon disappears, double spaces collapse to one, an accidental space around the equals sign is trimmed, and a duplicate name keeps only the last value. That behavior is convenient in demo code and dangerous in production, because the output no longer matches what the browser actually sent. The Cookie to JSON Converter follows the opposite rule: any deviation from the strict request profile produces an explicit error so the developer notices the malformed input instead of inheriting a guess, in line with the parsing rules described in RFC 6265.
| Profile rule | Strict behavior in this tool | Common lenient behavior |
|---|---|---|
| Pair separator | Exactly "; " (semicolon plus one ASCII space) | Accepts ";", "; ", or any whitespace |
| Spaces around "=" | Rejected as malformed | Trimmed silently |
| Empty pair (";;") | Rejected | Skipped or normalized |
| Trailing semicolon | Rejected | Stripped before output |
| Duplicate names | Rejected with explicit error | Last-wins, silently |
| Percent sequences | Preserved literally as "%2F" and so on | URL-decoded without warning |
| Equals inside value | Only the first "=" is structural | May split at later "=" signs |
| Set-Cookie prefix | Explicit error, no output | Misparsed as request cookies |
The same strict profile is applied on the way back. When you reverse a flat JSON object into a header value, the tool decodes string escapes to recover the original characters, but it does not URL-encode, normalize, sort members, or invent Set-Cookie attributes. Member order from the lexical scan is preserved for output convenience, although the cookies themselves carry no semantic order and a server can interpret values using application-specific rules this converter does not know.
Convert a Bulk Cookie Header to JSON in Your Browser
- Open the Cookie to JSON Converter in a new tab.
- Choose the "Cookie to JSON" direction.
- Paste either a bare header value such as SID=abc; lang=en-US; cart=42 or the same line with an exact Cookie: prefix. Outer ASCII spaces around the pasted line are trimmed for convenience.
- Click Convert. Each pair is split only at its first "=", names are checked against the RFC token profile, values are checked against the cookie-octet or DQUOTE-wrapped cookie-octet profile, and duplicate or prototype-risk names are rejected before any map is built.
- Review the read-only output. Every preserved string is shown alongside the total pair count. A zero-length output or any validation failure replaces the previous result with an explicit error rather than appending to it.
- Copy the complete local output to your clipboard. If the browser denies clipboard access, the full output stays visible so you can select it manually.
The conversion runs entirely in your current tab, so a header carrying session secrets never has to leave the page. For the related two-direction pattern, the Convert Cookie Headers to JSON and Back in Your Browser guide walks through the same pair in both directions and explains how to slot the converter into a local debug pipeline.
Rebuild a Cookie Header From Reviewed JSON
- Open the Cookie to JSON Converter and switch to "JSON to Cookie" mode.
- Paste exactly one nonempty JSON object whose values are all strings, for example {"SID":"abc","lang":"en-US","cart":"42"}. Numbers, booleans, null, arrays, nested objects, comments, trailing commas, and text after the object are rejected before any header is built.
- Click Convert. The tool performs a duplicate-aware lexical scan so that escaped spellings such as "a" and "\u0061" are detected as the same key, even though ordinary JSON.parse would silently retain only one.
- Each decoded key is validated as an RFC token and each decoded value as an accepted cookie-value. An escaped newline fails because its decoded control character is not cookie-value data.
- Review the rebuilt header value. Accepted pairs are joined with the exact "; " separator in the order the lexical scan encountered them.
- Copy the result. Editing input or switching direction clears the prior output, the prior error, the pair count, the clipboard status, and any clipboard timer, so a stale "Copied" message cannot reappear after the input has changed.
Limits, Boundaries, and Error Behavior
The strict profile is enforced through a small, fixed set of boundaries that change whether a request can be converted at all. Anything outside the boundary is rejected; the tool never slices, caps, samples, or partially returns input, and a zero or invalid output length is rejected before any read-only text is published.
| Boundary | Exact limit or rule |
|---|---|
| Input length | Exactly 100,000 UTF-16 code units; the next unit is rejected |
| Output length | Exactly 200,000 code units; zero or invalid length is rejected |
| Silent truncation | None; maxLength is not used to prevent typing |
| Cookie-to-JSON input | Bare value or exact Cookie: field-name prefix only |
| Set-Cookie input | Explicit error; no misleading JSON |
| JSON-to-Cookie input | One nonempty JSON object, string values only |
| Blocked names | __proto__, prototype, constructor rejected in both directions |
| Duplicate names | Rejected case-sensitively, no first-wins or last-wins |
| Network use | None; no document.cookie reads, no HTTP requests, no uploads |
Percent sequences are not URL-decoded at any point: %2F stays the three characters percent, two, and F. Accepted quote characters surrounding a quoted value are preserved in JSON and in the reverse conversion because they are part of the serialized Cookie field value used by this tool. The internal map for forward conversion uses a null prototype so the keys __proto__, prototype, and constructor are blocked as a defense-in-depth boundary against downstream prototype pollution, even though the underlying map has no prototype to leak.
When a Cookie Converter Is the Right Tool (and When It Is Not)
Reach for the Cookie to JSON Converter when you are debugging the Cookie request field on the wire, moving a reviewed string map into JSON for an HTTP client or a server log, or producing a request-header value from reviewed JSON strings without touching a real browser. It is also a good fit when you want to verify a captured header against the strict request profile before forwarding it elsewhere, because the explicit error on malformed input is exactly the kind of friction you want during that review.
Do not use it to inspect the browser cookie store, to construct a Set-Cookie response header, to preserve attributes such as Domain, Path, Expires, Max-Age, Secure, HttpOnly, SameSite, Partitioned, Priority, or extension names, to decode an application's session format, to decide whether a cookie is safe, or to sanitize credentials before sharing. The Cookie request field by definition cannot reveal a cookie's expiry, permitted hosts, permitted paths, secure-only state, or HttpOnly state, because those attributes are set by the server in Set-Cookie and never returned by the browser. For a workflow that wants those attributes as part of a portable file, the Convert Cookie JSON to Netscape guide covers the separately scoped Netscape format. For general JSON cleanup, use the JSON Formatter, JSON Validator, or JSON Minifier; for unrelated markup cleanup, use the HTML Cleaner.
Cookie headers frequently carry live session tokens. Treat every pasted value as a credential: keep it inside your browser tab, avoid pasting it into shared logs, and rotate any session that has been exposed. The strict profile is designed to surface malformed input rather than to hide it, so the error message you see is usually the difference between what you pasted and what the browser actually sent.