What is the difference between a cookie sent as 'Set-Cookie: sid=abc' and one sent as 'Set-Cookie: sid=abc; Max-Age=3600', in terms of how long the browser keeps it?
answer
- no Expires and no Max-Age = session cookie
- Max-Age/Expires present = persistent, on disk
- 'session' is the browser's definition, not yours
- session restore can outlive a browser close
- cookie lifetime != server-side session validity
basics
~20 sWith no Max-Age or Expires it is a session cookie: held in memory and dropped when the browsing session ends. With Max-Age=3600 it is persistent: written to disk and sent for one hour, surviving browser restarts.
solid answer
~50 sA `Set-Cookie` with **neither `Expires` nor `Max-Age`** creates a **session cookie**. The browser keeps it only for the current browsing session — typically in memory — and discards it when the browser closes. `Set-Cookie: sid=abc; Max-Age=3600` creates a **persistent cookie**: the browser records an expiry time (now plus 3600 seconds), stores it durably, and keeps sending it until that moment passes, across restarts.\n\nTwo caveats matter in practice. First, "session" is the *browser's* notion, not your server's: modern browsers restore session cookies when they reopen tabs after a crash or with "continue where you left off" enabled, so a session cookie can outlive a visible close. Second, neither kind is guaranteed — a browser may evict a cookie early under storage pressure or user clearing. Server-side session state should therefore have its own expiry; the cookie lifetime is a hint, never the authority on whether a session is still valid.
code
http · 1 lineHTTP/1.1 200 OK\nSet-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax\nSet-Cookie: theme=dark; Path=/; Max-Age=3600go deeper
State the rule plainly: no lifetime attribute means it dies with the browser session; Max-Age or Expires makes it persist on disk.
Add that 'session' is defined by the browser, mention session restore and incognito, and note that Max-Age is relative while Expires is absolute.
Tie it to auth design: short session cookie plus rotated persistent refresh cookie, server-side expiry as the authority, graceful degradation when the cookie is gone.
Frame the tradeoff between friction and risk across device classes, and set organisation-wide policy for remember-me lifetime, revocation and session invalidation.
## Two lifetimes, one header\n\nEvery cookie is either a *session cookie* or a *persistent cookie*, and the only thing that decides which is the presence of a lifetime attribute on `Set-Cookie`.\n\n- **No `Expires`, no `Max-Age`** → session cookie. The user agent keeps it for "the current session" and discards it at the end.\n- **`Max-Age=<seconds>` or `Expires=<HTTP-date>` present** → persistent cookie. The browser computes an absolute expiry time, stores the cookie durably (on disk), and sends it on matching requests until that time passes.\n\n```\nSet-Cookie: sid=abc; Path=/; HttpOnly <- session cookie\nSet-Cookie: sid=abc; Path=/; Max-Age=3600; HttpOnly <- persistent, one hour\n```\n\n## What "session" actually means\n\nThe session is defined by the **user agent**, not by your application and not by the protocol. It roughly means "until the browser process for this profile exits". That definition leaks in ways that surprise people:\n\n- **Session restore.** Chrome, Firefox and Edge routinely persist session cookies across a restart when the user has "reopen tabs" configured, or after a crash recovery. A session cookie can therefore survive a full close and reopen — you cannot rely on it disappearing.\n- **Mobile.** On iOS and Android, browsers are suspended rather than exited for days. The session may last far longer than a desktop one.\n- **Multiple windows.** All windows of the same profile share one cookie store; closing one window ends nothing. Private/incognito windows have a **separate** store that is destroyed when the last such window closes.\n\nSo "session cookie" is a good default for login state on shared machines, but it is a usability preference, not a security control.\n\n## Why persistence is a product decision\n\nA session cookie means the user logs in again after a restart. A persistent cookie means "remember me". The pattern most applications use:\n\n- Short-lived **access/session cookie** — often a session cookie, or a persistent one with a small `Max-Age` (minutes).\n- Longer-lived **refresh/remember-me cookie** — persistent, with `Max-Age` in days or weeks, marked `HttpOnly` and `Secure`, and rotated on each use so theft is detectable.\n\nEither way the server keeps its own expiry for the underlying session record. The cookie's lifetime governs whether the *browser sends* the credential; only server-side state governs whether the credential is still *valid*. Anyone who treats the cookie lifetime as the session timeout has built a system where a stolen cookie is valid for as long as the attacker keeps it — the client's clock and the client's storage are not yours to trust.\n\n## The absolute-time trap\n\n`Max-Age` is relative (seconds from receipt); `Expires` is an absolute HTTP-date. A persistent cookie's expiry is evaluated against the **client's** clock, so a device whose clock is wrong by a day will expire cookies early or late. `Max-Age` is largely immune to this because the browser converts it to an absolute time at receipt using its own clock, so only clock *drift* during the lifetime matters rather than absolute skew.\n\n## Nothing is guaranteed\n\nA persistent cookie is best-effort storage. It can vanish before its expiry because the user cleared browsing data, because the browser evicted it under per-domain or global cookie limits, because storage pressure triggered cleanup, or because a privacy policy capped its lifetime. Applications must therefore degrade gracefully: a missing cookie means "treat as anonymous and re-authenticate", never an error state, and never irreversible data loss (do not store the only copy of anything in a cookie).\n\n## Quick decision guide\n\n- Kiosk or shared terminal, or highly sensitive app → session cookie, plus a short server-side idle timeout.\n- Consumer app with "keep me signed in" → persistent cookie with an explicit `Max-Age`, user-visible and revocable server-side.\n- Anything non-essential (theme, last-used tab) → persistent, small `Max-Age`, and code that works fine when it is gone.
- If a session cookie can survive a browser restart via session restore, is it still worth using one for login?Yes, as a default that matches user expectation on shared machines, but not as a security boundary. Pair it with a server-side idle timeout and absolute session lifetime so that the authoritative expiry lives on the server, where session restore, clock changes and cookie-store quirks cannot affect it.
- Should the session cookie's lifetime be the session timeout?No. The cookie lifetime only controls whether the browser keeps sending the credential; the server must independently track when the session expires and reject stale ones. Otherwise a cookie copied off the machine stays valid indefinitely, since the attacker simply never lets it expire in their own store.
A session cookie is a paper wristband at a venue — it exists only while you are inside tonight. A persistent cookie is a membership card in your wallet with a printed expiry date, still there next month.
saying these in an interview costs you the question
- Believing a session cookie is always destroyed when the browser closes
- Treating the cookie's Max-Age as the authoritative session timeout with no server-side expiry
- Thinking a persistent cookie is guaranteed to exist until its expiry
- Confusing 'session cookie' with a cookie whose name happens to be sessionid
- Assuming incognito shares the normal cookie store