HTTP Cookie Parser

How to use this tool

1. Choose Set-Cookie response headers or a Cookie request header, then paste the value.
2. Review attributes, prefix and SameSite warnings, and cookie values.
3. Load a parsed cookie into the editor, change fields, and copy the rebuilt header.

Read and rebuild HTTP cookie headers

A Set-Cookie response header defines one cookie and its attributes, while a Cookie request header sends one or more name-value pairs back to a server. This parser keeps those formats separate: paste multiple response cookies one per line, or inspect the semicolon-separated pairs in a request header. A comma in an Expires date is kept within its cookie record.

Load any parsed cookie into the editor to change its name, value, or attributes and see a rebuilt header update as you type. Unrecognized Set-Cookie attributes are shown and retained by the response builder. The request builder emits only name=value pairs; it never adds response-only fields such as Secure, HttpOnly, or SameSite. All parsing, editing, and value inspection runs in your browser.

HTTP cookie attributes

The tool highlights two common configuration issues: SameSite=None without Secure, and cookie names that use the __Secure- or __Host- prefixes without meeting their requirements. A __Host- cookie needs Secure and Path=/, and must omit Domain. The same warnings update as you edit fields in the response builder. These checks explain header settings; they do not contact a site or test how a particular browser will store the cookie.

SameSite explained

• Strict: cookie is never sent in cross-site requests. Most secure; may break OAuth redirects.
• Lax: cookie is sent on top-level navigations and GET requests from external sites. Default in modern browsers.
• None: cookie is sent in all contexts (third-party). Requires Secure flag.

Third-party cookie deprecation

Google originally planned to deprecate third-party cookies in Chrome by 2024 but reversed course in 2024, opting instead for a user-choice model rather than a blanket ban. Browser policies continue to differ and can change. The CHIPS (Cookies Having Independent Partitioned State) mechanism allows a cookie to be scoped to a top-level site rather than shared across all sites. This parser displays the Partitioned attribute and can preserve it when rebuilding a response header; browser acceptance still depends on the cookie attributes and browser policy. Partitioned cookies are commonly paired with SameSite=None; Secure.

Cookie vs. localStorage for authentication

For storing authentication tokens, cookies with HttpOnly and Secure flags are significantly more secure than localStorage:

• HttpOnly cookies are inaccessible to JavaScript, eliminating the risk of token theft via XSS. localStorage is directly readable by any script.
• Secure flag ensures the cookie is only sent over HTTPS, preventing interception on insecure networks.
• CSRF risk: cookies are automatically included in cross-site requests, creating CSRF vulnerability. Mitigate with SameSite=Lax or Strict and CSRF tokens for state-changing operations.

Cookie size limits

• Per cookie: ~4,096 bytes (4 KB) including the name, value, and attributes
• Per domain: approximately 50 cookies, though this varies by browser
• Total per domain: approximately 4 KB × 50 = ~200 KB maximum, though browsers may evict older cookies when limits are reached

For larger data storage needs, use localStorage (5–10 MB) or IndexedDB.

Cookie values can be inspected on demand with URL decoding, JSON formatting, or JWT header and payload decoding. These actions are opt-in and operate only on the displayed value. JWT inspection does not verify a signature, so decoded claims are not proof that a token is valid. Malformed input is reported in the result area without interrupting the rest of the parser.