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?

juniormust knowfreq 58%

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 s

With 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 s

A 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.

A `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 line

http

HTTP/1.1 200 OK\nSet-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax\nSet-Cookie: theme=dark; Path=/; Max-Age=3600

go deeper

for a junior

State the rule plainly: no lifetime attribute means it dies with the browser session; Max-Age or Expires makes it persist on disk.

for a middle

Add that 'session' is defined by the browser, mention session restore and incognito, and note that Max-Age is relative while Expires is absolute.

for a senior

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.

for a principal

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.

## 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

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

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

▾common follow-ups2 questions

▾analogy~20 s

▾red flags5 flags

§ context

▾related questions5 questions

▾related topics3 topics

answer

go deeper

context