HTTP Cookie Prefix Validator｜Check __Host- and __Secure- Rules Per Line

Paste your Set-Cookie headers and this tool checks each line against the RFC 6265bis rules for the __Host- and __Secure- prefixes. Every line gets a PASS / FAIL badge, and failing lines spell out exactly which requirement broke alongside a table of the parsed attributes — Path, Domain, Secure, HttpOnly, SameSite. No backend, just paste and read.

💡 About this tool

__Host- and __Secure- are cookie prefixes: special name prefixes that make the browser enforce attribute requirements. If a cookie name starts with one of them and the requirements aren't met, the browser silently ignores the entire Set-Cookie header. That silent drop is exactly why "I set __Host-session but the user never gets logged in" turns into an afternoon of head-scratching.

The two prefixes ask for different things. __Secure- only requires the Secure attribute. __Host- is stricter: on top of Secure, it demands Path=/ (exactly root) and no Domain attribute at all. Dropping Domain pins the cookie to the exact host that set it, which shuts down subdomain cookie tossing — an attacker on evil.example.com can't write a cookie that gets sent to app.example.com. The moment you put a CDN or load balancer in front of a multi-host setup, that distinction is the one people miss.

This validator takes a whole batch of Set-Cookie lines, detects each prefix, and applies only the rules that prefix triggers. Failing lines say things like "__Host- must not set a Domain attribute" so you can drop a copy of your production headers straight in, or wire the same mental check into a code review before it hits CI.

🧐 Frequently Asked Questions

What's the difference between __Host- and __Secure-? Strictness. __Secure- needs only the Secure flag. __Host- needs Secure plus Path=/ exactly and no Domain attribute. __Host- gives the strongest host-binding guarantee of the two.

Are the prefixes case-sensitive? No. Browsers treat __Host- and __host- (lowercase) as the same prefix and enforce the same rules. RFC 6265bis switched to case-insensitive matching to close a bypass: a server that compares cookie names case-insensitively could otherwise be tricked by a lowercase variant sent without Secure. This tool applies the rules case-insensitively too.

Why does a __Host- cookie with Path=/api fail? __Host- requires Path=/ — exactly root. A sub-path like /api breaks the requirement and the browser throws the cookie away. If you need a scoped path, use __Secure- instead.

How are lines with no prefix treated? A line without a privileged prefix has no requirement to check, so it's marked PASS and labelled "(no prefix)". The attribute table still renders so you can eyeball what was actually set.

Does anything I paste leave my machine? No. Every line is parsed in your browser and the Set-Cookie headers you paste are never sent to a server, so dropping in real production cookie names and values stays local.

📚 Why the rule lives in the name, not an attribute

The neat trick behind __Host- and __Secure- is that the requirement is baked into the name rather than carried as an attribute. A Set-Cookie header travels server-to-browser with all its attributes, but when the browser later sends the cookie back (the Cookie request header), only the name and value go along — Secure, Path, and friends are gone. So the server can't inspect an incoming cookie and confirm it was really stored with Secure. The prefix closes that gap: encode the requirement into the name, and the mere arrival of a cookie called __Host-session is proof the browser enforced Secure and host-binding when it stored it, because the spec mandates that the browser silently discards any non-conforming Set-Cookie. Guaranteeing safety through a naming convention instead of a new attribute is also why prefixes shipped backward-compatibly — they ride on the existing cookie wire format without changing a single byte of its grammar.