See what a browser keeps from each Set-Cookie line, what it rejects and how to harden it
Runs in your browser. Nothing you type is sent anywhere. Checked against sources on 17 Oct 2026.A Set-Cookie header asks the browser to store one cookie with attributes such as Secure, HttpOnly, SameSite, Path and Max-Age. This analyzer reads each header as a browser does, shows what is kept and ignored, explains a rejection such as SameSite=None without Secure, and caps lifetimes at 400 days as browsers do.
Paste one or more Set-Cookie lines from the response headers.
Enter the page address the response came from; https://www.example.com/ is assumed.
Read each cookie as the browser stores it, or the reason the browser drops it.
Fix the flagged attributes, or switch to Build to write a hardened Set-Cookie line.
Cookies fail quietly. A browser that refuses a cookie shows no error to the visitor, and the login simply does not stick. Paste the Set-Cookie lines from the response, with the address of the page, and each cookie is read by the same algorithm browsers use.
What you see for each cookie. The name and value; the attributes the browser keeps, with the last one winning when an attribute repeats; the ones it ignores, such as a misspelt Expires date or an unknown attribute; the expiry it will actually store; whether it is sent to subdomains; and the Cookie header the page would send back.
Why a browser rejects a cookie.
| Cause | Rule |
|---|---|
| SameSite=None without Secure | Current browsers drop it |
__Secure- name without Secure |
Prefix rule |
__Host- name with Domain, without Secure, or a Path other than / |
Prefix rule |
| Secure set over plain http | Not stored |
| Domain of another site, or a bare suffix such as com | Domain rule |
| Name and value over 4,096 bytes | Size limit |
Hardening advice. Accepted cookies are checked too: Secure everywhere, HttpOnly for session cookies so scripts cannot read them, an explicit SameSite, a lifetime that matches the job, no Domain unless subdomains need it, and the __Host- prefix for session cookies, which locks a cookie to one origin. Lifetimes over 400 days are cut to 400 days by current browsers, and the page shows the date they will really expire.
Build mode. Fill in a form and copy a Set-Cookie line that passes every check above.
The parsing follows RFC 6265 and the current cookie draft, and it passes all 218 enabled cases of the http-state test suite written for browsers. Only one-label domains are treated as public suffixes; the full list is not bundled. Nothing you paste leaves the browser.
Common causes are SameSite=None without Secure, a Secure cookie sent over plain http, a Domain attribute naming another site, a __Host- or __Secure- name without the attributes its prefix requires, or a cookie over 4,096 bytes. Paste the Set-Cookie line and the page address to see which rule the browser applied.
Current browsers accept SameSite=None only together with the Secure attribute, so the cookie must be set and sent over HTTPS. Without Secure the whole cookie is dropped. SameSite=None lets the cookie travel with cross-site requests, so use it only for cookies that embedded content or third-party flows really need.
A cookie whose name starts with __Host- is accepted only with Secure, Path=/ and no Domain attribute. The browser then guarantees it was set by this exact host over HTTPS and is sent only to it, so a subdomain or an http page cannot overwrite it. Session cookies benefit most.
Current browsers cap a cookie's lifetime at 400 days, about 13 months, whatever Expires or Max-Age asks for, following the current cookie standard draft. A cookie with neither attribute is a session cookie and is removed when the browser session ends, although restoring tabs can keep it longer.
Expires gives an absolute date, such as Wed, 21 Oct 2026 07:28:00 GMT; Max-Age gives a number of seconds from now. When both are present, Max-Age wins. Max-Age=0 or a past Expires date deletes the cookie, which is how servers log a user out.
Every cookie that scripts do not need should have it, and session or authentication cookies always should: HttpOnly hides the cookie from JavaScript, so an injected script cannot steal the session. Cookies that the page's own code reads, such as a theme or consent setting, have to leave it off.
Rates and rules change; check the source before you rely on a figure.
Still stuck? Ask about Set-Cookie Header Analyzer and anybody who knows can answer. No account needed.
On the related tools: JWT Decoder – Paste a token to read its header, payload and expiry · Passphrase Generator – Three to ten random words you can actually remember · Bcrypt Generator – Generate a bcrypt hash for a test user or a config file.