Set-Cookie Header Builder and Checker
Fill in the name, value and options to get a correct Set-Cookie header, or paste a header you already send to see what is wrong with it.
Worked examples
A sign-in cookie
Name session, value abc123, prefix none, path /, lasts 3600 seconds, SameSite Lax, Secure and HttpOnly on
Set-Cookie: session=abc123; Path=/; Max-Age=3600; Secure; HttpOnly; SameSite=Lax
Choosing the __Host- prefix also forces Secure, Path=/ and no Domain.
About Set-Cookie Header Builder and Checker
A cookie is set with one header, but small flags on that header decide whether the cookie can be stolen or misused. Secure keeps it off unencrypted connections. HttpOnly hides it from scripts, so a cross-site scripting bug cannot read a session cookie. SameSite limits when the browser sends the cookie on requests from other sites, which blunts cross-site request forgery. Name prefixes such as __Host- ask the browser to enforce extra conditions. Getting any of them wrong leaves a gap or a cookie that browsers simply refuse.
The builder writes the header in the right order and applies the rules browsers enforce: SameSite=None needs Secure, a __Host- cookie needs Secure, Path=/ and no Domain, and names and values may use only allowed characters. In check mode you paste a header you already send and every attribute is read back, with problems listed first and a note on each flag that is missing. It also reminds you of limits such as the 4096 byte size and the 400 day cap on lifetimes.
How to use Set-Cookie Header Builder and Checker
- Choose Build a header, then enter the cookie name and value.
- Set the path, how long it lasts, SameSite, and whether it is Secure and HttpOnly. Pick a prefix if you want one.
- Read the notes for anything that browsers would reject or that weakens the cookie.
- Copy the header into your server code, or choose Check a header and paste one to review.
Common uses
- Setting up a sign-in cookie with the right protections
- Finding out why a cookie is not being stored
- Reviewing the cookies a framework sets by default
- Preparing a cookie for use inside an embedded frame
Frequently asked questions
Why was my cookie rejected?
The common reasons are SameSite=None without Secure, a __Host- or __Secure- name without the flags it requires, a value containing spaces, commas or semicolons, and a cookie over 4096 bytes. The checker finds all of these.
What does SameSite do?
Strict sends the cookie only on requests that start from your own site. Lax also sends it when someone follows a link to your site. None sends it on all requests, including from other sites, and must be used with Secure. Browsers treat a missing value as Lax.
What is the __Host- prefix?
A cookie whose name starts with __Host- is only accepted if it is Secure, has Path=/ and has no Domain. That stops a less trusted sub-domain from overwriting it, so it is the strongest choice for a sign-in cookie.
Should I set Domain?
Usually not. Without Domain the cookie goes only to the exact host that set it. Setting it shares the cookie with every sub-domain, which widens who can read or overwrite it.
How long can a cookie last?
Browsers cap the lifetime at about 400 days, whatever you set. Max-Age is in seconds and takes priority over Expires when both are present.