Cookie Builder
Build a Set-Cookie HTTP header string from a cookie name, value, domain, path, max-age, and security flags (Secure, HttpOnly, SameSite) per RFC 6265.
Input
Which hosts can receive the cookie. Leave blank to default to the current host.
URL path that must exist in the request for the cookie to be sent.
How long the cookie persists, in seconds. Leave blank for a session cookie.
Output
The name=value pair plus any attributes you set, semicolon-separated.
Guides
What is the Cookie Builder?
The Cookie Builder assembles a correctly formatted Set-Cookie HTTP response header from structured fields — name, value, domain, path, expiration, and security flags — following RFC 6265, the specification that defines how cookies work on the web. Instead of hand-writing the semicolon-separated attribute string and hoping you got the syntax right, fill in the fields and copy the finished header.
How to use it
- Enter a Cookie Name and Cookie Value — the only required fields. Together they form the
name=valuepair every cookie starts with. - Optionally set a Domain (which hosts receive the cookie) and Path (which URLs receive it —
/covers the whole site). - Set Max-Age to a number of seconds if the cookie should persist after the browser closes. Leave it blank for a session cookie that disappears when the tab is closed.
- Toggle Secure and HttpOnly as needed, and pick a SameSite policy.
- The Set-Cookie Header box updates automatically — copy it straight into your server response, or download it as a text file.
Cookie attributes explained
- Domain — which hosts can receive the cookie. Omit it and the cookie is scoped to the exact host that set it (not including subdomains).
- Path — the URL path that must be present in a request for the cookie to be sent.
/matches everything;/apirestricts it to API routes. - Max-Age — lifetime in seconds. Without it (and without an
Expiresdate), the cookie is a session cookie and is deleted when the browser closes. - Secure — the cookie is only sent over HTTPS connections. Required whenever
SameSite=Noneis used. - HttpOnly — blocks the cookie from being read via
document.cookiein JavaScript, which helps mitigate cross-site scripting (XSS) attacks against session tokens. - SameSite — controls cross-site request behavior.
Strictsends the cookie only on same-site requests (strongest CSRF protection);Lax(the modern browser default) also allows it on top-level navigations;Nonesends it on all cross-site requests but requiresSecure.
FAQ
Why is my cookie value being URL-encoded?
Cookie values cannot legally contain semicolons, commas, whitespace, quotes, backslashes, or control characters. If your value contains any of these, the tool automatically URL-encodes it with encodeURIComponent so the resulting header stays valid — decode it with decodeURIComponent on the receiving end.
What's the difference between Max-Age and Expires?
Both control cookie lifetime. Max-Age is a relative number of seconds and is simpler to reason about; Expires is an absolute date. Where both are present, Max-Age takes precedence per RFC 6265, which is why this tool exposes only Max-Age.
Do I need Secure and HttpOnly?
For anything sensitive — session IDs, auth tokens — yes. HttpOnly stops JavaScript (and therefore XSS payloads) from reading the cookie, and Secure stops it from ever being sent in plaintext over HTTP.
Can I use this for document.cookie in client-side JavaScript?
The header this tool produces is written for server responses (the Set-Cookie HTTP header). Client-side document.cookie assignments use a similar but not identical syntax and can't set HttpOnly at all, since that flag exists specifically to keep the cookie out of JavaScript's reach.
Privacy
This tool runs entirely in your browser. The cookie name, value, and attributes you enter are never sent to or stored on our servers.