Cookie to JSON Converter

How to use

1. 1.Choose Cookie to JSON and paste a strict bare Cookie request value or an exact Cookie: prefix followed by the value.
2. 2.Or choose JSON to Cookie and provide one nonempty object whose decoded keys and string values satisfy the Cookie profiles.
3. 3.Convert, review every preserved string and pair count, then copy the complete local output.

About Cookie to JSON Converter

Cookie to JSON converts the value of an HTTP Cookie request header into a flat JSON object and converts a flat JSON string object back into a Cookie request-header value. Both directions run entirely in the current browser tab. Paste either a bare header value such as SID=abc; lang=en-US or include an exact Cookie: field-name prefix. Output is plain text in a read-only area and is never sent to Lizely or another service.

This tool handles Cookie request headers only. It does not parse Set-Cookie response headers and does not treat Domain, Path, Expires, Max-Age, Secure, HttpOnly, SameSite, Partitioned, Priority, or extension attributes as request cookies. 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 cannot reveal a cookie's expiry, permitted hosts, permitted paths, secure-only state, or HttpOnly state. Pasting an exact Set-Cookie: prefix therefore produces an explicit error instead of misleading JSON.

Cookie input follows a strict RFC 6265 request serialization profile. Every pair is name=value. Multiple pairs must be separated by exactly a semicolon followed by one ASCII space. Spaces around the equals sign, a missing separator space, multiple separator spaces, a trailing semicolon, and an empty pair are rejected rather than normalized. If the optional field-name is included, Cookie must be followed immediately by a colon; Cookie : is malformed. Matching of the field-name itself is case-insensitive, so COOKIE:a=1 is accepted. Outer ASCII spaces around the pasted line are ignored for convenience.

Only the first equals sign in each pair is structural. Additional equals signs remain value data, preserving Base64-like padding such as abc==, signed tokens, query strings, and URLs containing equals signs. Empty values such as preference= are valid. An empty name or a pair without equals fails. Cookie names use the RFC token profile and remain case-sensitive, so SID and sid are two distinct names. Names containing spaces, separators, controls, or other non-token characters fail.

Values use the RFC cookie-value profile: an unquoted sequence of permitted cookie octets or the same sequence wrapped in double quotes. Percent sequences are not URL-decoded, escaped, normalized, or interpreted. For example, %2F remains the three characters percent, 2, and F. Raw spaces, commas, semicolons, backslashes, controls, and characters outside cookie-octet are rejected. Quote characters surrounding an accepted 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.

A JSON object cannot preserve two members with the same decoded name without choosing a winner. Cookie input with duplicate names is rejected instead of using first-wins or last-wins behavior. Names are compared case-sensitively. JSON input receives a duplicate-aware lexical scan before conversion, so escaped spellings such as a and \u0061 are detected as the same key even though ordinary JSON.parse would silently retain only one. Cookie-to-JSON output is assembled with a null-prototype internal map.

The keys __proto__, prototype, and constructor are blocked in both directions as a defense-in-depth prototype-pollution boundary. Even though JSON text can represent those strings and the internal forward map has no prototype, rejecting them prevents downstream code from treating generated output as a safe assignment source. The tool does not claim that arbitrary downstream JSON handling is secure; consumers must still parse and merge untrusted data safely.

JSON-to-Cookie mode accepts exactly one nonempty JSON object. Every property value must be a JSON string. Numbers, booleans, null, arrays, nested objects, comments, trailing commas, and text after the object are rejected. JSON string escapes are decoded before Cookie validation. An escaped newline therefore fails because its decoded control character is not cookie-value data. Duplicate decoded keys fail before serialization. Accepted pairs are joined with the same exact semicolon-plus-one-space separator.

The reverse direction validates the decoded key as an RFC token and the decoded value as an accepted cookie-value. It does not percent-encode forbidden characters, add quotes automatically, remove quotes, sort members, infer paths, or generate Set-Cookie attributes. JSON object 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.

Input is limited to exactly 100,000 UTF-16 code units and complete output is limited to 200,000 code units. Exact limits are accepted and the next unit is rejected. The interface does not use maxLength to silently prevent typing, and conversion never slices, caps, samples, skips, or partially returns input. A zero or invalid output length is rejected. Any error removes the previous successful result before publishing the message.

Editing input or switching direction clears prior output, error, pair count, clipboard status, and clipboard timer. Clipboard writing is asynchronous. Every copy attempt receives a generation identifier, and a mounted-state guard prevents an older permission response from restoring Copied after an edit, direction change, retry, or unmount. Clipboard denial leaves the complete output visible for manual selection. No cookies are read from document.cookie, no browser cookie store is modified, and no HTTP request is made.

Use this converter 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. Cookie headers often contain live session secrets. Keep them private and rotate credentials that have been exposed. For general JSON work, use JSON Formatter, JSON Validator, or JSON Minifier. For unrelated markup cleanup, use HTML Cleaner.

Methodology & sources

Reject empty input and text above 100,000 UTF-16 code units. For Cookie to JSON, reject controls and Set-Cookie, accept only an exact optional Cookie: prefix, require name=value pairs separated by exactly semicolon plus one space, and split each pair only at its first equals without trimming internal boundary spaces. Validate names as RFC tokens, values as cookie-octets or DQUOTE-wrapped cookie-octets, duplicates case-sensitively, and prototype-risk names explicitly; serialize a null-prototype map with two-space JSON indentation. For JSON to Cookie, lex exactly one nonempty object with string values, decode escapes while detecting duplicate decoded keys, apply the same Cookie profile, and join pairs with the exact separator. Preserve percent sequences and accepted quotes. Reject invalid, zero-length, or above-200,000-code-unit output. Invalidate result and generation-guard clipboard completion on every edit or mode change.

• RFC 6265 — HTTP State Management Mechanism
• IETF HTTPbis — draft-ietf-httpbis-rfc6265bis
• MDN — Cookie header
• MDN — Set-Cookie header

Frequently asked questions

Can this convert a Set-Cookie response header?

No. Set-Cookie carries response attributes such as Domain, Path, Expires, Secure, HttpOnly, and SameSite. This tool handles only strict Cookie request-header pairs.

Why does the tool reject spaces around equals or unusual semicolon spacing?

It follows the strict Cookie request serialization boundary: name=value pairs separated by exactly semicolon plus one space. It does not silently normalize malformed input.

Are percent-encoded values, URLs, or extra equals signs decoded?

No. Percent sequences and permitted punctuation are preserved literally, and only the first equals sign in each pair separates its name from its value.

Why are duplicate and prototype-related names rejected?

A JSON object cannot preserve duplicate decoded names, and prototype-related keys are dangerous in downstream assignment code. Rejection avoids hidden overwrites and reduces pollution risk.

Related tools

• 🔧JSON Formatter
  Format, minify, and validate JSON in your browser — pretty-print or compress with pinpoint error locations.
• ✅JSON Validator
  Check if JSON is valid, pinpoint syntax errors by line and column, and see a structure diagnostic, in-browser.
• JSON Minifier
  Turn strict JSON into a compact JSON.parse and JSON.stringify result while explicitly rejecting duplicate keys and unsafe numeric rewrites.
• HTML Cleaner
  Normalize an HTML fragment through the browser parser and optionally remove comment nodes without previewing or executing the result.
• 🆎ASCII Table
  Look up every standard 7-bit ASCII code with exact decimal, hexadecimal, octal, and binary values.
• BOM Remover
  Remove exactly one leading U+FEFF from pasted decoded text locally while preserving every internal, trailing, or second leading occurrence.

• Compare Text Differences in VS Code with a Browser Diff Checker