Build a Set-Cookie line with Secure, HttpOnly, SameSite and __Host-, checked as you go
Runs in your browser. Nothing you type is sent anywhere. Checked against sources on 17 Oct 2026.Fill in the name, value and lifetime and tick the protections; the Set-Cookie line is written as you go and checked the way a browser checks it. A __Host- name must have Secure and Path=/ and no Domain, SameSite=None needs Secure, and anything longer than 400 days is cut to 400 days, so the line you copy is one browsers will keep.
Paste or type your input.
Choose the options you need.
Press Ctrl+Enter, then copy or download.
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.
| 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.
The rest of the article, and all 6 questions about Set-Cookie Header Analyzer, are on the Set-Cookie Header Analyzer page.
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.
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.