What are the options (attributes) in a cookie?

HighIntermediateJavascript

By FrontendAtlas Team · Updated Mar 2, 2026

Quick Answer

Cookie options are attributes on Set-Cookie that control lifetime, scope, and security. Learn Expires vs Max-Age, Domain and Path scoping, Secure/HttpOnly/SameSite protections, and when to use Partitioned cookies.

Answer

The core idea

A cookie is not just name=value. Real behavior is controlled by attributes in the Set-Cookie header: lifetime, which paths/domains can receive it, and how strongly it is protected against client-side attacks and cross-site request abuse.

In interviews, high-quality answers group cookie options into three buckets: lifetime, scope, and security.

HTTP

Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

Attribute	What it controls	Common values	Key note
`Expires`	Absolute expiry date/time	HTTP-date string	Creates persistent cookie until that date.
`Max-Age`	Relative lifetime in seconds	`3600`, `86400`	Often preferred; when both are present, Max-Age takes precedence.
`Domain`	Which hosts receive the cookie	`example.com`	If omitted, cookie is host-only (more restrictive).
`Path`	URL path scope	`/`, `/admin`	Limits sending by path, but is not a security boundary by itself.
`Secure`	Transport requirement	flag	Cookie sent only over HTTPS.
`HttpOnly`	JavaScript access	flag	Blocks `document.cookie` reads/writes for that cookie.
`SameSite`	Cross-site sending policy	`Strict`, `Lax`, `None`	Reduces CSRF risk; `None` requires `Secure`.
`Partitioned`	Storage partitioning for cross-site contexts	flag	Used for CHIPS-style isolation; requires `Secure`.

Cookie attributes define behavior far more than the raw value does.

Lifetime options: Expires vs Max-Age

No Expires/Max-Age means a session cookie (typically removed when browser session ends).
Expires uses an absolute timestamp.
Max-Age uses relative seconds and is less timezone-sensitive.

HTTP

Set-Cookie: theme=dark; Max-Age=2592000; Path=/; SameSite=Lax
Set-Cookie: promo=on; Expires=Wed, 31 Dec 2026 23:59:59 GMT; Path=/

Scope options: Domain and Path

Use the narrowest scope possible. Over-broad cookies increase accidental leakage across subdomains or app sections.

HTTP

Set-Cookie: hostOnly=1; Path=/
# No Domain attribute -> only current host receives it

Set-Cookie: shared=1; Domain=example.com; Path=/
# Sent to example.com and subdomains (broader scope)

Security options that matter most

For auth/session cookies, baseline hardening is usually:

HttpOnly to reduce token exposure via XSS.
Secure to avoid plaintext transport.
SameSite policy aligned with your cross-site needs (often Lax or Strict).

HTTP

Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

Important frontend limitation

document.cookie can set basic attributes like Path, Expires, and SameSite (browser support dependent), but it cannot set HttpOnly.

If you need secure auth cookies, set them server-side via Set-Cookie response headers.

JAVASCRIPT

// Client-side cookie write (limited control)
document.cookie = 'theme=dark; Path=/; Max-Age=2592000; SameSite=Lax';

// HttpOnly cannot be set from JavaScript.

Use case	Suggested attributes	Why
Session authentication	`HttpOnly; Secure; SameSite=Lax/Strict; Path=/`	Balances usability with strong baseline CSRF/XSS protection.
Cross-site embedded app/session	`SameSite=None; Secure` (+ optional `Partitioned`)	Allows cross-site sending with explicit secure transport.
UI preference cookie	`Max-Age` or `Expires`, narrow `Path`	Persistent behavior without over-scoping sensitive state.

Choose attributes by risk profile, not by habit.

Interview one-liner

Cookie options are Set-Cookie attributes that define lifetime, scope, and security; strong answers specifically mention Max-Age/Expires, Domain/Path, and Secure/HttpOnly/SameSite.

Practical scenario
An app stores a login session and a theme preference. The session cookie must be locked down for security, while the theme cookie can be broader and persistent.

Common pitfalls

Missing Secure or HttpOnly on auth cookies.
Using SameSite=None without Secure (rejected by modern browsers).
Setting overly broad Domain values that expose cookies across subdomains.
Assuming Path alone provides strong security isolation.

Trade-off or test tip
Test cookie behavior in real browser flows: same-site navigation, cross-site redirect, embedded iframe context, and HTTPS-only environments to verify attributes behave as intended.

Still so complicated?

Think of cookie attributes like delivery rules on a package: when it expires, which addresses can receive it, and what security checks are required before handoff.