HTTP Cookie Builder

Generate a Set-Cookie header with all attributes — Path, Domain, Max-Age, Expires, Secure, HttpOnly, and SameSite.

Cookie Name: sessionHttpOnly: YesSameSite: Lax

Cookie name

Cookie value

Stays on your device — never written into the shareable link, because a cookie value is often a session token.

Path

Domain (optional)

Max-Age (seconds, optional)

Expires (HTTP date, optional)

SameSite

HttpOnly(block JS access)Secure(HTTPS only)

Set-Cookie header

Set-Cookie header attributes explained

The Set-Cookie HTTP response header stores a small piece of data in the browser. Key attributes: HttpOnly prevents JavaScript from reading the cookie (mitigates XSS); Secure ensures it is only sent over HTTPS; SameSite=Lax or Strict protects against CSRF; and Max-Age sets an expiry in seconds relative to the current time (preferred over Expires).

For related security headers, see the HTTP Security Header Generator or the CSP Generator.

Built and maintained by Meet Shah · Last updated 30 July 2026

What this tool is used for

Building a Set-Cookie header with the attributes you actually intend.
Getting the SameSite and Secure combination right for a cross-site case.
Producing a header to compare against one a server is emitting.
Checking how Max-Age and Expires interact.
Producing a header for a test or a curl command.

Frequently Asked Questions

What does SameSite actually control?: Whether the cookie is sent on requests originating from another site. `Strict` never sends it cross-site, `Lax` sends it only on top-level navigations, and `None` always sends it. Lax has been the browser default since 2020, which quietly broke a great deal of cross-site embedding.
Why does SameSite=None need Secure?: Because browsers reject the combination otherwise — a cookie declaring `SameSite=None` without `Secure` is dropped silently, not downgraded. That pairing is enforced precisely because a cross-site cookie over plain HTTP is the easiest thing in the world to steal.
What is the difference between Max-Age and Expires?: `Max-Age` is a relative lifetime in seconds; `Expires` is an absolute date. When both are present, `Max-Age` wins in every browser that supports it. Relative is usually safer, since an absolute date depends on the client's clock being right.
What does HttpOnly protect against?: Reading the cookie from JavaScript, which means an XSS payload cannot exfiltrate a session token via `document.cookie`. It does nothing against CSRF — the browser still attaches the cookie to requests — so HttpOnly and SameSite defend against different attacks and are both worth setting.
Why should a cookie value never go in the URL?: Because URLs are logged everywhere: server access logs, proxy logs, browser history, and the `Referer` header sent to third parties. This tool keeps the value out of its own shareable link for exactly that reason — a session token in a URL is a token in half a dozen logs.

Common errors and gotchas

Using `SameSite=None` without `Secure`, which browsers reject outright.
Omitting HttpOnly on a session cookie, which leaves it readable by any script on the page.
Setting a domain broader than needed, which shares the cookie with every subdomain.
Assuming a path restriction is a security boundary, which it is not.
Setting both Max-Age and Expires with different values, where precedence differs by browser.