Set-Cookie Builder
Inspect Cookie / Set-Cookie attributes and consistency in your browser. No input is sent to a server. Use it for first-pass operational troubleshooting.
Status
Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.
How to use
Enter cookie name/value and attributes, then Build. You can copy the Set-Cookie output.
Notes (this tool)
- Secure is recommended when SameSite=None.
About this page
What does this tool do?
Enter cookie name/value and attributes to generate a Set-Cookie header string.
Useful for safely composing SameSite/Secure and related attributes.
Set-Cookie basics
- Set-Cookie is a response header that instructs the browser to store a cookie.
- Domain/Path define scope; Expires/Max-Age define lifetime.
- SameSite=None typically requires Secure.
Typical use cases
- Organize login cookie requirements
- Adjust SameSite for API/SPA flows
- Design Domain/Path/expiry combinations
Key attributes
- Domain / Path: scope
- Expires / Max-Age: lifetime (either is fine)
- Secure / HttpOnly: security flags
- SameSite: cross-site sending control
Syntax (how to write)
Set-Cookie is formatted as "name=value; Attr1; Attr2=..." with semicolon-separated attributes. name/value are required; attributes are optional.
- Expires is a UTC date string (e.g., Wed, 21 Oct 2015 07:28:00 GMT)
- Max-Age is an integer number of seconds
- Secure/HttpOnly are flags (no values)
SameSite (quick)
SameSite controls whether cookies are sent in cross-site contexts. It often affects login, embeds, and external payment flows.
- Lax: a common default for many use cases
- Strict: stricter (may not send on external navigations)
- None: allow cross-site (often requires Secure)
Expires vs Max-Age
Expires is an absolute timestamp; Max-Age is seconds from now. Max-Age is often easier because you don’t worry about server time skew/timezones.
- Some setups include both (depending on compatibility/policy).
- To delete: use Max-Age=0 and/or an Expires date in the past
Security guidance (recommended defaults)
For sensitive session cookies, start with Secure/HttpOnly and adjust SameSite as needed.
- Use Secure when HTTPS is available
- Use HttpOnly when JS access is not needed
- Only use SameSite=None when cross-site use is required
Suggested workflow
- Define the goal (session/preferences/tracking, etc.)
- Build with minimal attributes → add only what’s needed
- Validate the output using Cookie Inspect
- Check request sending via Request Headers Parser
Common pitfalls
- Forgetting Secure with SameSite=None
- Domain/Path mismatch prevents sending
- Bad Expires/Max-Age causes immediate expiration
Privacy & analytics considerations
Cookies are used for auth and analytics. Design lifetime and SameSite based on purpose, and avoid storing unnecessary data.
What this tool does
- Assemble Set-Cookie strings
- Configure common attributes
- Copy-and-use output
Operational notes
- Behavior can vary with browser implementation differences and default changes.
- Duplicate cookie names and Path or Domain differences often cause operational issues.
Referenced specs
- RFC 6265 (HTTP Cookies)
- MDN: Set-Cookie
FAQ
Should I use Expires or Max-Age?
Either works, but Max-Age is often easier to handle.
What are the requirements for SameSite=None?
Secure is required in most browsers.
What is Partitioned?
In some environments it is used for partitioned cookies. Use it only when you know you need it.
References
Next to view (diagnostic order)
These links are generated from site_map rules in recommended diagnostic order.
- How to Diagnose Same-Name Cookie Collisions — Resolve unstable behavior by tracing same-name cookie path/domain variants, overwrite order, and send collisions
- Content-Type Inspect — Parse Content-Type and inspect MIME/charset
- Request Headers Parser — Parse request headers into structured data
- Response Headers Parser — Parse response headers into structured data
- Request/Response Diff — Compare header differences between request and response