Also available in: Español · Português · Français · العربية
Set-Cookie header: attributes, SameSite and the __Host- prefix
Assemble a cookie header or paste one in, and find out whether a browser will store it or silently throw it away.
What is the Set-Cookie header?
Set-Cookie is how a server asks a browser to remember something. The header is a name and a value followed by attributes that decide how long the cookie lives, which requests carry it, and whether script can read it: Expires, Max-Age, Domain, Path, Secure, HttpOnly and SameSite.
Where those rules are written is more surprising than the rules themselves. RFC 6265, the published standard from 2011, defines the first six. It contains the word SameSite exactly zero times, and neither __Host- nor __Secure- appears in it at all. Those live in draft-ietf-httpbis-rfc6265bis, an Internet-Draft that has never been promoted to an RFC — and revision 22, the current one, carries the expiry date 4 June 2026.
Every browser implements the draft. So the rules that decide whether your session cookie is safe are, formally, in an expired document, while the standards-track one says nothing about them. Both facts are checkable in two files, and this page marks which document each attribute comes from.
How to use it
- Type or paste the header. Just the field value, without the Set-Cookie: prefix. The attribute buttons and the text field are the same thing, so toggling one rewrites the other.
- Read the verdict first. The top line says whether a browser will store this cookie or reject it, because those are the only two outcomes that matter and the second one is invisible at runtime.
- Use the fix button if it is rejected. It rewrites the cookie with the __Host- prefix and the three attributes that prefix demands, which is the strongest form a cookie can take.
The prefixes are enforced by silence
A cookie whose name begins with __Host- must carry Secure, must have Path=/ exactly, and must have no Domain attribute. One beginning with __Secure- needs only Secure. Get any of those wrong and the browser does not warn you or log anything — it simply declines to store the cookie, and the next request arrives without it. That is why this class of mistake usually presents as a login that stopped working rather than as a header problem.
The two prefixes are not the same rule, and treating them alike is the common error. __Secure- permits a Domain and any Path; __Host- forbids the Domain precisely because that is what pins the cookie to one exact host instead of sharing it across every subdomain. If a subdomain you do not fully control can set cookies, that difference is the whole security boundary.
The prefixes are also case-sensitive, in the specification's own wording. A name beginning with __host- in lower case receives none of the protection while looking exactly as though it does, so this page reports that as its own finding rather than staying quiet about it.
SameSite=None follows the same pattern: it requires Secure, and without it the cookie is rejected. That catches out embedded and cross-site flows constantly, because the value that sounds the most permissive is the one with an extra requirement attached.
What this page does not do
It checks one header in isolation. It cannot know whether you are on HTTPS, and Secure cookies are dropped over plain HTTP regardless of how correct the header looks; nor can it know your domain, so it cannot tell you whether a Domain attribute you set is one you are actually allowed to set.
It also does not cover Partitioned, the CHIPS attribute, as a rule to enforce. Partitioned appears zero times in 6265bis revision 22 — it is specified in a separate draft — so this page lists it as defined elsewhere rather than pretending it belongs to the same document as the rest.
And it reports what the specifications say, not what your framework does. Most frameworks set cookies through a helper with its own defaults, and several set SameSite=Lax for you whether you asked or not. Checking the header you actually send is the useful step; this page tells you what that header means.
Why is it free?
The rules are a small table and the parsing happens in your own browser. Nothing you type is uploaded, nothing is logged, and there is no account to create.
No sign-up, no limits, and no watermark on anything you copy.