Splitting a raw cookie header into names, values, and flags
'session=abc123; theme=dark; Secure; HttpOnly' parses into names 'session, theme, Secure, HttpOnly' with corresponding values 'abc123, dark, (flag), (flag)' -- two actual name=value cookie pairs, plus two attribute flags that don't carry a value of their own.
Secure and HttpOnly aren't cookies with data in them -- they're attributes describing how the cookie(s) in this string should be handled (Secure means only sent over HTTPS, HttpOnly means inaccessible to JavaScript) -- this parser correctly recognizes them as flags rather than trying to force them into a name=value shape they don't have.
This raw semicolon-separated format is exactly what you'd see in a Cookie request header or a Set-Cookie response header -- breaking it apart like this is useful for debugging exactly what a server sent or a browser is sending, without manually eyeballing a long semicolon-delimited string.
Why HttpOnly showing up here reveals something about the source
Semicolon split. Expires dates that contain a semicolon inside quotes are not handled. If this string came from JavaScript's document.cookie, it would never actually contain Secure or HttpOnly -- those flags are only visible in the raw Set-Cookie response header, since HttpOnly's entire purpose is hiding the cookie (and by extension, that flag) from JavaScript's access to document.cookie. Seeing HttpOnly in a parsed string confirms it came from a raw header, not from client-side script.
A real Set-Cookie header for an Expires attribute contains a comma-formatted date (like 'Expires=Wed, 21 Oct 2026 07:28:00 GMT') that itself could confuse a naive comma-or-semicolon-based parser -- this tool splits specifically on semicolons, which correctly handles a comma inside a date value without breaking it apart, though a semicolon appearing unexpectedly within a quoted value could still cause a mismatch.
Multiple cookies from different Set-Cookie headers are each their own separate header line in practice (a response can send several Set-Cookie headers), while a single Cookie request header can legitimately contain many semicolon-separated name=value pairs together -- this tool parses one combined string of pairs and flags, matching the request-header format most closely.
Related header and storage debugging tools
For parsing the full set of raw request or response headers a cookie string came from, the HTTP Header Parser handles the broader header block.
For inspecting localStorage or sessionStorage instead of cookies, the Web Storage Inspector covers that different browser storage mechanism.
Frequently Asked Questions (FAQ)
Why do Secure and HttpOnly show '(flag)' instead of a real value?
Because they're cookie attributes, not name=value pairs -- Secure and HttpOnly describe handling rules for the cookie(s) in the string rather than carrying their own data, so this parser correctly labels them as flags rather than inventing a value for them.
If HttpOnly appears in this parsed output, does that mean JavaScript can read the cookie?
No -- actually the opposite confirms something useful: document.cookie in a browser would never include an HttpOnly-flagged cookie's Secure/HttpOnly attributes at all, since JavaScript can't see those flags for an HttpOnly cookie. Seeing HttpOnly in this parsed string means it came from a raw Set-Cookie response header, not from client-side script.
Does this handle a cookie's Expires date correctly?
Semicolon split. Expires dates that contain a semicolon inside quotes are not handled. It splits on semicolons, which correctly handles a comma inside a formatted Expires date (like 'Wed, 21 Oct 2026...') without breaking it apart -- though an unusual value containing an actual semicolon inside quotes could still confuse this simple splitter.
Does this parse a Cookie request header or a Set-Cookie response header?
It's built for the semicolon-separated combined format most similar to a Cookie request header (multiple name=value pairs together). A Set-Cookie response header for a single cookie also includes attributes in a similar semicolon-separated shape, which this parser also handles correctly for the example shown.
What if a cookie value itself contains a semicolon?
Since this parser splits on semicolons, a value containing an actual semicolon character (which would need to be encoded per cookie specifications) could be split incorrectly -- correctly encoded cookie values shouldn't contain a raw semicolon in the first place.
