The Set-Cookie header is an HTTP response header sent by a server to instruct the browser to store a cookie. It contains the cookie name and value, along with optional attributes (flags) like Domain, Path, Expires, Max-Age, Secure, HttpOnly, and SameSite. Browsers use these cookies for session management, personalization, and tracking. The full syntax is defined in RFC 6265.

A Set-Cookie string consists of a name=value pair followed by semicolon-separated attributes. Key challenges include: (1) The Expires attribute contains commas inside its date value, which can break naive split(';') parsing. (2) Boolean flags like Secure, HttpOnly, and Partitioned have no = sign. Our parser handles these edge cases using regex-aware splitting and proper attribute detection.

SameSite controls when cookies are sent with cross-site requests, providing CSRF protection. Three values are supported:
Strict — Cookie is only sent with same-site requests (best security).
Lax — Cookie is withheld on cross-site subrequests (e.g., images/iframes) but sent on top-level navigations like clicking a link. This is the modern default in most browsers.
None — Cookie is sent with all cross-site requests, but must also set the Secure flag. Without Secure, SameSite=None cookies are rejected by browsers.

Expires specifies an absolute date/time (e.g., Wed, 21 Oct 2025 07:28:00 GMT) when the cookie expires. Max-Age specifies a relative lifetime in seconds from the time the cookie is set (e.g., Max-Age=3600 means 1 hour). If both are present, Max-Age takes precedence per RFC 6265. A Max-Age of 0 or negative immediately expires the cookie (deletes it). A session cookie has neither Expires nor Max-Age and is deleted when the browser closes.

The HttpOnly flag prevents client-side JavaScript from accessing the cookie via document.cookie. This is a critical security measure against XSS (Cross-Site Scripting) attacks — even if an attacker injects malicious scripts, they cannot steal HttpOnly cookies. Session tokens and authentication cookies should always use HttpOnly.

These are special prefixes that enforce additional security requirements on browsers:
__Secure- — The cookie must be set with the Secure flag. Browsers reject cookies with this prefix if Secure is missing.
__Host- — The cookie must be set with Secure, must have Path=/, and must not have a Domain attribute (must be host-only). This provides the strongest origin-binding guarantee.
Our parser automatically detects these prefixes and validates compliance.

Modern browsers (Chrome, Firefox, Edge) reject SameSite=None cookies that do not also include the Secure attribute. This is enforced to prevent insecure cross-site cookie leakage. If you set SameSite=None without Secure, the cookie is silently discarded. Our parser highlights this as a critical configuration error.

Partitioned cookies (also known as CHIPS — Cookies Having Independent Partitioned State) are a privacy-focused feature that ties a cookie to the top-level site context. A partitioned cookie set by third-party.com embedded on site-a.com is separate from the same cookie when embedded on site-b.com. Partitioned cookies must include the Secure flag and should use SameSite=None. This is part of the effort to phase out third-party cookies while preserving legitimate cross-site use cases.

Yes. A server can send multiple Set-Cookie headers in a single HTTP response — one per cookie. Our parser supports batch mode: paste multiple lines, and each line is parsed independently. This is especially useful when copying response headers from browser DevTools or curl -I output.

Cookie values often contain percent-encoded characters (e.g., %20 for space, %3D for =). Our parser auto-decodes URL-encoded values using decodeURIComponent() and displays both the raw and decoded versions when they differ. This is particularly useful for JWT tokens, JSON payloads, or user data stored in cookies.

The Priority attribute (supported in Chromium-based browsers) hints at the cookie's importance: Low, Medium, or High. When the browser needs to evict cookies (e.g., due to storage limits), lower-priority cookies are removed first. This is not part of the IETF standard but is widely implemented.