Gera Tools

HTTP Cookie Attributes Reference

All Set-Cookie attributes — Domain, Path, Expires, HttpOnly, SameSite, Partitioned.

Reference for every HTTP Set-Cookie attribute — Domain, Path, Expires, Max-Age, Secure, HttpOnly, SameSite and Partitioned — with security implications and browser behaviour. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is the difference between Expires and Max-Age?

Expires sets an absolute expiry date in HTTP-date format, while Max-Age sets a lifetime in seconds from receipt. If both are present Max-Age wins in modern browsers. With neither, the cookie is a session cookie that is cleared when the browser session ends.

The Set-Cookie response header carries a name/value pair plus attributes that control the cookie’s scope, lifetime and security posture. Getting these right is the difference between a hardened session token and a hijackable one. This reference lists every standard attribute with its behaviour and security implications, searchable by name.

How it works

A cookie is set with Set-Cookie and returned by the browser in the Cookie request header for matching requests. Attributes after the first ; shape where and when it is sent:

Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600

Domain and Path set the scope; Expires/Max-Age set lifetime; Secure and HttpOnly restrict transport and script access; SameSite governs cross-site sending; Partitioned opts into CHIPS partitioned storage. Name prefixes __Secure- and __Host- add browser-enforced requirements.

Attribute quick-reference

AttributeWhat it controlsSecurity implication
DomainWhich hosts receive the cookieOmitting it scopes to the exact origin — safer; adding it widens scope to all subdomains
PathURL path prefix that must matchNarrower paths limit exposure but are not a security boundary between same-origin pages
ExpiresAbsolute expiry timestampPersistent after browser close; expires at the given date
Max-AgeLifetime in seconds from receiptWins over Expires when both are present; 0 or negative deletes the cookie immediately
SecureHTTPS-only transportPrevents cookie from travelling over plaintext; mandatory for auth tokens
HttpOnlyHides cookie from JavaScriptStops XSS payloads reading the value; should always be set on session identifiers
SameSite=StrictOnly sent on same-site requestsMaximum CSRF protection; breaks login redirect flows
SameSite=LaxSent on same-site + top-level GET navigationsBrowser default since Chrome 80; good balance for session cookies
SameSite=NoneSent on all cross-site requestsRequires Secure; needed for embedded content and third-party auth
PartitionedSeparate jar per top-level siteCHIPS spec; allows cross-site cookies to survive third-party cookie removal

A production session token should combine all protective attributes:

Set-Cookie: __Host-session=TOKEN; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=7200
  • __Host- prefix forces Secure, Path=/ and no Domain — the browser rejects any cookie that does not meet all three.
  • HttpOnly blocks script access, so XSS cannot steal the token.
  • Secure ensures it only travels over HTTPS.
  • SameSite=Lax provides default CSRF protection without breaking navigation.
  • Max-Age=7200 gives a two-hour session; longer lifetimes increase exposure if a token is leaked.

Tips and notes

  • Session cookies (no Expires/Max-Age) are cleared when the browser session ends.
  • Always combine HttpOnly + Secure + SameSite on auth cookies.
  • Use the __Host- prefix to pin a cookie to one exact host and path /.
  • Omitting Domain scopes the cookie to the exact host — usually what you want.
  • Partitioned (CHIPS) keeps a cross-site cookie in a per-top-site jar, surviving third-party cookie phase-out.
  • Prefer Max-Age over Expires — it is a relative duration and avoids clock-skew bugs between client and server.