Cookie Header Parser

The Cookie Header Parser decodes browser-sent Cookie headers and server-sent Set-Cookie headers into structured, readable formats, extracting cookie names, values, and security attributes like HttpOnly, Secure, SameSite, expiration, domain scope, and path. Paste a header like session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Strict and get a clear breakdown of every attribute with explanations of what each one does.

Understanding HTTP Cookies

Cookies are the web's primary mechanism for maintaining state between requests. HTTP itself is stateless -- every request is independent, and the server has no built-in way to remember that two requests came from the same user. Cookies solve this by letting the server store a small piece of data in the browser, which the browser then sends back with every subsequent request. This is how login sessions work, how shopping carts persist across page loads, and how sites remember your language preferences.

The cookie lifecycle starts when a server includes a Set-Cookie header in an HTTP response. This header contains the cookie's name and value, plus optional attributes that control its lifetime, scope, and security properties. The browser stores the cookie and includes it in the Cookie header of future requests to that domain. A single Set-Cookie header sets one cookie, but a single Cookie header can carry many cookies, separated by semicolons.

What makes cookies tricky is the number of attributes that affect their behavior. The Domain and Path attributes control which URLs receive the cookie. The Secure flag restricts transmission to HTTPS. The HttpOnly flag prevents JavaScript from reading the cookie, protecting against cross-site scripting (XSS) attacks. The SameSite attribute controls whether the cookie is sent with cross-origin requests, which is the primary defense against cross-site request forgery (CSRF). Getting these attributes right is critical for both functionality and security, and this parser helps you verify them by showing each attribute with a plain-language explanation of what it does.

How to Parse a Cookie Header

1. Paste a Cookie or Set-Cookie header value into the input field.
2. Select the header type (Cookie for request headers, Set-Cookie for response headers).
3. Click Parse to extract all cookies and their attributes into a structured view.
4. Review the decoded values, attribute explanations, and any security recommendations.

Cookie Header Parsing Examples

Parsing a Browser Cookie Header

Input (Cookie header):

session_id=abc123def456; theme=dark; lang=en-US; _ga=GA1.2.123456789.1609459200

Parsed Output:

Parsing a Set-Cookie Response Header

Input (Set-Cookie header):

session_id=abc123def456; Path=/; Domain=.example.com; Expires=Thu, 01 Jan 2026 00:00:00 GMT; HttpOnly; Secure; SameSite=Strict

Parsed Output:

When to Use the Cookie Header Parser

• Debugging authentication issues -- Inspect session cookies to verify they are being set correctly with proper domain, path, and expiration values.
• Auditing cookie security -- Check that session cookies have HttpOnly, Secure, and SameSite flags set to prevent XSS and CSRF attacks.
• Analyzing third-party cookies -- Identify tracking cookies from analytics, advertising, and social media widgets and understand their scope.
• Troubleshooting cross-domain cookies -- Verify Domain and SameSite settings when cookies are not being sent in cross-origin requests.
• Compliance review -- Inventory all cookies a site sets, their purposes, and their lifetimes for GDPR or CCPA documentation.
• Incident response -- During a security incident, quickly parse all cookies to identify session tokens, their scope, and whether they are properly secured.

How Cookie Headers Work

Cookie vs. Set-Cookie

These two headers serve opposite directions of the HTTP cookie flow:

• Set-Cookie is sent by the server in a response to create or update a cookie on the browser. Each Set-Cookie header sets one cookie with its attributes.
• Cookie is sent by the browser in a request, containing all cookies that match the current URL's domain and path. Multiple cookies are semicolon-separated.

Cookie Attribute Reference

SameSite Attribute Values

• Strict -- Cookie is never sent on cross-site requests. Best for sensitive session cookies.
• Lax -- Cookie is sent on top-level navigation (clicking a link) but not on cross-site subrequests (images, iframes, AJAX). This is the browser default.
• None -- Cookie is sent on all cross-site requests. Requires the Secure flag.

Cookie Size and Count Limits

Browsers impose limits on cookies that you should be aware of:

When these limits are exceeded, browsers silently drop the oldest cookies. If your application suddenly loses session state, exceeding cookie limits is a common but often overlooked cause.

Practical Tips for Cookie Security

The most important rule for session cookies is to always set all three security flags: HttpOnly, Secure, and SameSite. The HttpOnly flag prevents JavaScript from accessing the cookie via document.cookie, which means an XSS vulnerability cannot steal your session token. The Secure flag ensures the cookie is never sent over unencrypted HTTP, even if a user accidentally visits the HTTP version of your site. And SameSite=Strict (or at minimum Lax) prevents the cookie from being sent in cross-site requests, which is the primary defense against CSRF attacks. Omitting any one of these flags leaves a gap in your security posture.

Cookie domain scoping is another area where mistakes are common. If you set Domain=.example.com (with the leading dot), the cookie is sent to example.com and every subdomain -- including evil.example.com if an attacker can register a subdomain. For session cookies, it is safer to omit the Domain attribute entirely, which restricts the cookie to the exact origin that set it. Only use domain scoping when you genuinely need to share cookies across subdomains, such as for single sign-on between app.example.com and api.example.com.

Watch out for the interaction between SameSite=None and the Secure flag. Modern browsers require Secure when SameSite=None is set -- if you omit Secure, the cookie is silently rejected. This requirement exists because SameSite=None tells the browser to send the cookie on cross-site requests, and doing so over unencrypted HTTP would expose the cookie to network eavesdroppers. If your third-party cookie is being silently dropped, check that both attributes are present.

Frequently Asked Questions

Why does my Set-Cookie header have no effect?

Common causes include: missing Secure flag when using SameSite=None, setting Domain to a different domain than the response origin, the browser blocking third-party cookies, or Path being set to a path that does not match the current page.

What is the difference between Expires and Max-Age?

Expires uses an absolute date (Thu, 01 Jan 2026 00:00:00 GMT), while Max-Age specifies seconds from now (3600 = 1 hour). When both are present, Max-Age takes precedence. If neither is set, the cookie is a session cookie and is deleted when the browser closes.

How can I tell if a cookie is a tracking cookie?

Common indicators include: names starting with _ga, _gid (Google Analytics), _fbp, _fbc (Facebook), or _uet (Bing). Cookies with Domain set to a third-party domain and long Max-Age values (often 1-2 years) are typically tracking cookies.

Why are my cookies not sent in cross-origin API requests?

Cross-origin requests require specific configuration on both the client and server. The client must set credentials: 'include' in the fetch options, and the server must respond with Access-Control-Allow-Credentials: true and a specific origin (not *) in Access-Control-Allow-Origin. The cookie also needs SameSite=None; Secure to be sent cross-origin.

What happens when a browser's cookie limit is reached?

Browsers silently evict the oldest or least-recently-used cookies to make room for new ones. There is no error or warning. If your application relies on many cookies, consider consolidating them into a single JSON-encoded cookie or moving state to server-side sessions.

How do cookie prefixes like __Secure- and __Host- work?

These are cookie name prefixes that enforce additional security requirements. A cookie named __Secure-session must have the Secure flag. A cookie named __Host-session must have both Secure and Path=/, and must not have a Domain attribute. These prefixes provide defense-in-depth against cookie manipulation attacks.

Related Tools

• HTTP Header Formatter - Parse and format HTTP headers including Set-Cookie
• CORS Header Explainer - Understand CORS headers that affect cookie transmission in cross-origin requests
• HTTP Status Code Lookup - Look up status codes for responses that set cookies
• User-Agent Parser - Parse User-Agent strings to understand which browser sent the cookies
• curl Command Builder - Build curl commands with cookie headers for testing