Why did the Set-Cookie header set successfully but the browser didn't save my cookie?
This is the most common issue. Browsers don't actively report errors; they silently drop non-compliant cookies. Common causes include: SameSite=None missing Secure, Secure cookies set on HTTP pages (localhost exception), __Host-/__Secure- prefix constraints not met, Domain/Path mismatch, exceeding the 4KB size limit, Max-Age being 0 or negative. We recommend first pasting your Set-Cookie headers into this tool to check warning badges and pinpoint the specific cause, then opening Chrome DevTools → Application → Cookies, looking under the relevant domain for a yellow warning triangle — hover to see the exact rejection reason.
What exactly is the difference between SameSite's Strict, Lax, and None? When should I use which?
Strict completely disallows cross-site sending — the most secure, but users clicking in from external links appear logged out, suitable for sensitive operations like payments/password changes. Lax is the default in Chrome 80+, allowing cookies to be sent during top-level GET navigation jumps (clicking an external link back to your site), but not for subresources like iframe/img/script/XHR/POST forms — recommended for most scenarios. None allows sending in all cross-site scenarios (for SSO single sign-on, third-party embedded iframes, cross-site API calls), but must be paired with Secure, otherwise the browser rejects it outright.
Why must SameSite=None be paired with Secure?
This is a rule Chrome has enforced since version 80 (February 2020), with Firefox, Edge, and Safari all following suit. Because SameSite=None explicitly allows cross-site cookie sending, attackers can more easily launch CSRF or eavesdrop in cross-site scenarios, so it must be paired with Secure (HTTPS encrypted transmission) to mitigate risk. If your SameSite=None cookie is set over HTTP, the browser simply drops it without storing it. This tool detects SameSite=None-without-Secure combinations and flags them with red warnings.
Should I use Max-Age or Expires? What's the difference?
Prefer Max-Age. Max-Age is relative time (expires after N seconds), doesn't depend on the client clock, and the browser starts counting down upon receipt; Expires is an absolute point in time, dependent on the user's local computer time (if a user sets their clock to 1970, the cookie expires immediately). When both are present, Max-Age takes priority (explicitly specified by RFC 6265). If neither is set, the cookie becomes a 'session cookie' that expires when the browser closes. This tool prompts when Expires is set without Max-Age, recommending Max-Age be added. Note: Max-Age is in seconds, not milliseconds.
What's the difference between Path=/ and not setting Path?
Path determines which URL path requests the browser will include this cookie on. When Path is not set, the browser defaults to 'the response URL with the last segment removed' — for example, when setting a cookie from /api/user/login, the default Path is /api/user/, so requests under / and /order/ won't carry this cookie. Explicitly setting Path=/ makes the cookie active across the entire site. Note that Path matching is prefix-based — Path=/api also matches /api/, /api/user, /api/v2/abc, etc. __Host- prefixed cookies require Path=/.
What's the difference between a Domain with a leading dot (like .example.com) and without?
In modern browsers (recent versions of Chrome, Firefox, Edge, Safari), the two are equivalent — both make the cookie apply to example.com and all its subdomains (a.example.com, b.c.example.com). The leading dot was old syntax from the RFC 2109 era; RFC 6265 explicitly ignores leading dots. However, the form without a dot is recommended for readability. This tool notes Domains with leading dots (not an error, but a legacy notation). Note: When Domain is not set, the cookie applies only to the current host (subdomains won't get it); setting Domain makes it apply to subdomains.
What are the __Host- and __Secure- prefixes? Can I skip them?
These are cookie name security prefixes introduced in RFC 6265bis to add hard constraints for high-security cookies: when browsers see a cookie name starting with __Host-, they enforce that Secure must be set, Path=/, and Domain must not be set — failing any condition, storage is outright rejected; the __Secure- prefix requires Secure to be set, with other attributes configurable. Cookies work fine without prefixes (most cookies don't use them), but __Host- is strongly recommended for high-security cookies like session identifiers and auth tokens, as it prevents subdomain/path-level cookie injection attacks. This tool automatically detects compliance for both prefix types.
Are HttpOnly cookies really secure? Do they prevent XSS and CSRF?
HttpOnly prevents JavaScript from reading cookie values via document.cookie, making it an important line of defense for <strong>mitigating XSS session theft</strong>, but it's not a silver bullet: XSS attackers can still initiate requests in the user's browser (which automatically carry cookies) to perform actions (this is CSRF territory); HttpOnly also doesn't defend against CSRF attacks (which require SameSite or CSRF tokens). The full trio of HttpOnly+Secure+SameSite=Lax/Strict used together achieves a baseline security level. Sensitive cookies (session, JWT, access_token) must be HttpOnly; don't expose them to frontend JS unless necessary. This tool warns on cookies missing HttpOnly.
What are Partitioned (CHIPS) cookies? When do I need them?
Partitioned is a new attribute Chrome introduced in preparation for third-party cookie phase-out, short for Cookies Having Independent Partitioned State (CHIPS). Traditional third-party cookies (like those set by ads/embedded services across multiple sites) are globally shared and can be used to cross-site track users. With Partitioned added, browsers store that third-party cookie separately per top-level site: the third-party cookie a user sees on Site A is completely independent from what they see on Site B, with no cross-site identity sharing. Use cases: embedded video/map/payment components, third-party chat plugins, cross-site SSO embedded iframes. Partitioned must be used with Secure, recommended with the __Host- prefix.
How much data can a single cookie hold? How many can be placed per domain?
Per RFC 6265, browsers must support at least 4096 bytes per cookie (including name, value, and attributes). Major browsers (Chrome/Firefox/Safari/Edge) enforce this limit; excess is silently truncated or dropped. Count limits vary by browser: Chrome allows ~180 per domain, Firefox ~150, Safari ~600 (and affected by ITP's 7-day purge policy), after which browsers evict the oldest cookies via an LRU strategy. We recommend cookies store only session identifiers — don't put large chunks of business data in cookies (store business data in localStorage or server-side sessions).
Does it support parsing Set-Cookie copied directly from Chrome DevTools? Do I need to remove prefixes manually?
Fully supported — no manual processing needed. You can go to Chrome DevTools → Network panel, click the target request, right-click the Set-Cookie value in the Response Headers section and copy directly (for multiple lines, Ctrl/⌘+click to multi-select or copy the whole block), then paste into this tool's input area. The tool automatically strips the Set-Cookie: prefix from the beginning of each line (case-insensitive), handles leading/trailing whitespace, correctly processes special characters like commas and semicolons in Expires dates, and correctly handles double-quoted cookie values.
Why do Chinese characters or special characters in cookie values become %XX form?
RFC 6265 requires cookie values to use only a safe subset of the ASCII character set, and cannot directly contain Chinese characters, spaces, commas, semicolons, etc. Many server-side frameworks automatically URL-encode (encodeURIComponent/Percent-encoding) non-ASCII characters when setting cookies, e.g., '你好' encodes to %E4%BD%A0%E5%A5%BD. Browsers also maintain the encoded form when sending them back. When this tool detects values containing %XX encoding, it automatically shows the decodeURIComponent-decoded original text next to the raw value with a green arrow for your convenience.
What's the difference between Set-Cookie and the Cookie request header?
They are headers in completely opposite directions: Set-Cookie is a response header (server → browser), appears only in responses, can appear multiple times, setting one cookie each time with full attributes (Secure/HttpOnly/Path/Domain/etc.); Cookie is a request header (browser → server), appears only once per request, containing flat name=value pairs (name1=v1; name2=v2) of all in-scope cookies, with no attribute information at all. That means servers cannot know from requests whether a cookie has HttpOnly or Secure set — attribute information is retained only by the browser when stored locally. To parse Cookie request headers, use the companion <a href='/network/http-cookie-parser/'>Cookie Request Header Parser</a>.
Why do my cookies disappear after a few days in Safari?
This is Safari's Intelligent Tracking Prevention (ITP) mechanism at work. Starting with ITP 2.1, if a user doesn't directly interact with a domain for 7 days (i.e., hasn't directly visited the domain's site), Safari purges all cookies and website data under that domain, regardless of how long Max-Age/Expires is set. This has the biggest impact on third-party embedded services, while main site cookies are unaffected as long as users keep visiting. Additionally, Safari's restrictions on third-party cookies are stricter than Chrome's. Solutions include: using the Partitioned attribute, requesting permissions via the Storage Access API, or refreshing cookies when users visit the main site. The troubleshooting section of this tool has more detailed Safari debugging guidance.
Does the tool support bulk parsing multiple Set-Cookie headers? Will cookie content be uploaded to servers?
Bulk parsing is supported. The input area supports pasting any number of multi-line Set-Cookie headers (such as pasting an entire response header block at once). Each Set-Cookie is parsed with independent numbering, with multiple attribute cards showing their respective attributes and warnings. All parsing happens entirely locally in your browser (pure frontend JavaScript processing). Cookie content is never uploaded to any server, no network requests are made, and sensitive information like sessions/tokens you paste never leaves your computer — use with confidence.
