Cookie Header Generator
Create a correct Set-Cookie header without memorising the rules. Choose the name, lifetime, scope and security attributes, and the generator enforces what browsers require (SameSite=None needs Secure, __Host- cookies need Path=/ and no Domain), warns about risky choices, and writes the matching code for PHP, Express, Python, JavaScript or Nginx.
- Runs in your browser
- No sign-up
- Free to use
How to use Cookie Header Generator
- Pick a preset such as Login session or Preference.
- Enter the cookie name and a placeholder value.
- Choose the lifetime, scope and security attributes.
- Choose the output and copy the header or code.
Cookie Header Generator features
Every attribute
Max-Age, Expires, Domain, Path, Secure, HttpOnly, SameSite and Partitioned.
Name prefixes
__Host- and __Secure- with their rules enforced.
Browser rules
Rejects combinations that browsers would silently drop.
Value encoding
Percent-encodes characters not allowed in cookie values.
Six outputs
Raw header, PHP, Express, Flask/Django, document.cookie and Nginx.
Nothing stored
Runs in your browser; use placeholders instead of real tokens.
When to use Cookie Header Generator
- Configuring a secure session cookie for a login system.
- Fixing cookies that stopped working after browsers changed SameSite defaults.
- Setting a cookie for an embedded widget that needs cross-site access.
- Deleting an old cookie that keeps coming back.
Cookie Header Generator FAQ
Which attributes should a session cookie have?
Secure, HttpOnly, SameSite=Lax or Strict, Path=/ and ideally the __Host- prefix with no Domain. That keeps it on HTTPS, away from JavaScript, away from most cross-site requests and locked to one host.
What is the difference between Lax, Strict and None?
Strict never sends the cookie on requests started by another site. Lax sends it when the user follows a normal link to your site, but not on cross-site form posts or embedded requests. None sends it everywhere and requires Secure.
What does the __Host- prefix do?
Browsers only accept a cookie named __Host-… if it is Secure, has Path=/ and has no Domain. That stops subdomains or insecure pages from overwriting it.
Max-Age or Expires?
Max-Age, a number of seconds, is preferred and wins when both are present. Expires is added as well for very old clients.
How do I delete a cookie?
Send the same name, Path and Domain with Max-Age=0 (or an Expires date in the past). Use the “Delete a cookie” preset.
Why can JavaScript not read my cookie?
Because it has HttpOnly. That is intended for session cookies; only set cookies without it when scripts genuinely need the value, and never for credentials.
How cookies are controlled
A server sets a cookie with a Set-Cookie response header containing a name, a value and attributes. The browser then sends the name and value back in the Cookie header of later requests that match the cookie’s scope. The attributes decide everything else: how long the cookie lives, which hosts and paths receive it, whether it travels over plain HTTP, whether scripts can read it and whether other sites can cause it to be sent.
Lifetime comes from Max-Age or Expires. Without either, the cookie is a session cookie and disappears when the browser session ends, although browsers that restore sessions may keep it longer. Browsers also cap lifetimes at 400 days. Scope comes from Domain and Path: leaving Domain out keeps the cookie on the exact host that set it, which is safer than sharing it with every subdomain.
The security attributes are where mistakes happen. Secure keeps the cookie off unencrypted connections. HttpOnly hides it from JavaScript, so a cross-site scripting bug cannot simply read the session. SameSite limits cross-site requests and is a strong defence against cross-site request forgery; browsers now treat cookies without it as Lax, which broke some embedded content and payment flows that relied on the old behaviour.
Prefixes add rules the browser checks. A cookie whose name starts with __Secure- must be Secure, and one starting with __Host- must also have Path=/ and no Domain. Because the browser refuses to store a prefixed cookie that breaks the rules, an attacker who controls a subdomain or an insecure page cannot plant a lookalike session cookie. Partitioned, part of the CHIPS proposal, gives an embedded service a separate cookie jar for each site that embeds it.
Cookie values cannot contain spaces, commas, semicolons, quotes or backslashes, so arbitrary text is usually percent-encoded and decoded again when read. Keep cookies small, since every request to the matching host carries them, and avoid storing personal or sensitive data in readable cookies. This page builds the header locally; use example values rather than live session identifiers while experimenting.