A local cookie converter can convert a strict HTTP Cookie request header into a flat JSON string map and convert a reviewed JSON object of strings back into a Cookie request-header value. The Cookie to JSON Converter handles both directions in the current browser tab, so pasted header or JSON data is never sent to Lizely or another service. It reads no cookies from document.cookie, changes no browser cookie store, and makes no HTTP request. The converter is deliberately strict rather than a cleanup utility: it expects name=value request pairs, uses an exact semicolon-plus-one-space separator, preserves literal percent sequences and extra equals signs inside values, and rejects ambiguous or unsafe input instead of silently normalizing it. That makes it useful for debugging a captured Cookie field, moving a reviewed string map into JSON, or producing a request-header value from reviewed JSON strings. It does not convert Set-Cookie response headers, reconstruct response attributes, decode an application’s session format, or determine whether a cookie is secure. Use it for the request-header conversion itself, review the full output, and keep any live credentials private.
Select the direction that matches your input
Choose the conversion mode according to the data you already have. The modes have different input contracts, so starting with the correct one avoids confusing a JSON object with a serialized Cookie field.
| Starting input | Mode | Result |
|---|---|---|
| A bare Cookie request value or an exact Cookie: prefix | Cookie to JSON | A flat JSON object whose property values are strings |
| One nonempty, flat JSON object | JSON to Cookie | A Cookie request-header value made from name=value pairs |
Both directions produce plain text in a read-only output area. The Cookie-to-JSON result uses two-space JSON indentation, while the reverse direction joins accepted pairs with the same exact semicolon-plus-one-space separator.
Convert a Cookie request header to JSON
- Open the converter and choose Cookie to JSON. This is the correct mode when you have the value of an HTTP Cookie request header.
- Paste the strict request value. A bare value such as SID=abc; lang=en-US is accepted. You may instead include an exact Cookie: field-name prefix followed immediately by the value. Do not paste a Set-Cookie response header.
- Select Convert. The converter validates the entire input before publishing a result. Accepted pairs become string properties in a flat JSON object.
- Review every preserved string and the reported pair count. Check that the names and values match the request field, then copy the complete output. If clipboard permission is denied, the full result remains visible for manual selection.
Cookie input: SID=abc; lang=en-US
Equivalent JSON map: { "SID": "abc", "lang": "en-US" }
Outer ASCII spaces around the pasted line are ignored for convenience. The optional field-name itself is case-insensitive, so COOKIE:a=1 is accepted, but the colon must follow Cookie immediately. A form such as Cookie : is malformed.
Turn a flat JSON string map into a Cookie value
Choose JSON to Cookie and provide exactly one nonempty JSON object. Every property value must be a JSON string. After decoding JSON string escapes, the converter validates each decoded name and value against the same Cookie profiles used in the forward direction.
JSON input: { "SID": "abc", "lang": "en-US" }
Equivalent Cookie value: SID=abc; lang=en-US
- Numbers, booleans, null, arrays, nested objects, comments, trailing commas, and text after the object are rejected.
- An escaped newline is decoded before validation, so it fails as a control character rather than being hidden inside the JSON text.
- Duplicate decoded property names fail before serialization rather than selecting a first or last winner.
- The converter does not percent-encode forbidden characters, add or remove quotes, sort members, infer paths, or generate Set-Cookie attributes.
JSON member order is retained for output convenience, but Cookie semantics should not depend on serialization order. A server may also interpret a cookie value according to application-specific rules that the converter cannot know.
Validation rules that prevent silent changes
The strict validation boundary is useful when debugging a request because it distinguishes a valid serialization from text that would require a guessed repair.
| Input scenario | Converter behavior |
|---|---|
| SID=abc; lang=en-US | Accepted as two pairs with the required separator space. |
| SID=abc;lang=en-US | Rejected because the required ASCII space after the semicolon is missing. |
| SID = abc | Rejected because spaces around the equals sign are not normalized. |
| SID=abc; | Rejected because a trailing semicolon creates an empty pair. |
| preference= | Accepted because an empty cookie value is valid. |
| token=abc== | Accepted because only the first equals sign separates the name from the value. |
| a=1; a=2 | Rejected because duplicate names cannot be preserved in the JSON object. |
| Set-Cookie: a=1 | Rejected with an explicit error because response headers are out of scope. |
| __proto__=x | Rejected because prototype-risk names are blocked. |
Names and values are checked separately
Cookie names must fit the RFC token profile and remain case-sensitive, so SID and sid are distinct names. An empty name or a pair without an equals sign fails. Values must be either an unquoted sequence of permitted cookie octets or that same sequence wrapped in double quotes. Raw spaces, commas, semicolons, backslashes, controls, and characters outside the cookie-octet profile are rejected. When a quoted value is accepted, its surrounding quote characters are preserved because they are part of the serialized Cookie field value. Percent sequences remain literal: %2F stays percent, 2, and F rather than becoming a decoded slash.
Duplicate and prototype-risk keys fail
Duplicate matching is case-sensitive, but it also occurs after JSON escapes are decoded. The JSON-to-Cookie scan therefore detects equivalent spellings such as a and \u0061 before an ordinary JSON parse could silently retain only one. The names __proto__, prototype, and constructor are blocked in both directions. Cookie-to-JSON uses a null-prototype internal map, but that does not make arbitrary downstream JSON assignment safe; consumers must still parse and merge untrusted data carefully.
Cookie request fields are not Set-Cookie responses
A Cookie request header contains name=value pairs sent by a browser. It does not carry the response attributes commonly found in Set-Cookie, including Domain, Path, Expires, Max-Age, Secure, HttpOnly, SameSite, Partitioned, Priority, or extension attributes. Those attributes are supplied by a server in a response and are not returned by the browser in the Cookie request field.
This request/response split is described by RFC 6265 and the IETF HTTPbis cookie specification. Consequently, 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 produces an explicit error rather than misleading JSON.
Keep secrets private and check the boundaries
- Processing stays in the browser. Both conversion directions run in the current browser tab, with no request to Lizely or another conversion service.
- The input boundary is explicit. Input can contain exactly 100,000 UTF-16 code units; that exact size is accepted and the next unit is rejected. The interface does not use maxLength to silently stop typing.
- Complete output is required. Output is limited to exactly 200,000 UTF-16 code units, with the exact limit accepted and the next unit rejected. Conversion never slices, caps, samples, skips, or partially returns the input, and a zero or invalid output length is rejected.
- Stale results are cleared. An error removes the previous successful result. Editing the input or changing direction clears the output, error, pair count, and clipboard status.
- Clipboard fallback remains available. Copying is asynchronous, but a permission denial does not hide the completed output; you can select it manually.
- Cookie fields often contain live secrets. Keep converted headers private and rotate credentials that have been exposed. Local processing prevents an upload, but it does not remove the sensitivity of session cookies.
Before using the result in a request, debugging note, or handoff document, compare the reported pair count with the visible pairs and verify every value. The final check is especially important when the source contains session identifiers, signed tokens, URLs, or Base64-like padding.