Your application sets a cookie with 'Set-Cookie: prefs=x; Max-Age=31536000' and expects it a month later, yet some users lose it. What browser behaviours remove a cookie before its stated expiry, and how do you design around that?

## The premise to unlearn\n\n`Max-Age=31536000` is a *request* for one year of storage. The browser is free to store it for less, and routinely does. Any design that assumes "I set it, therefore it is there" will fail for a measurable slice of users, and the failures look random because they depend on the user's browser, settings and behaviour rather than on your code.\n\n## 1. Lifetime caps imposed by the browser\n\nChromium and Firefox clamp cookie expiry to a maximum of roughly **400 days** from the time of setting, in line with the direction of RFC 6265bis; anything longer is silently reduced. That alone breaks the common "set it for ten years" idiom.\n\nPrivacy engines go much further, and the key distinction is **who wrote the cookie**:\n\n- Cookies written by JavaScript via `document.cookie` are treated with suspicion. Safari's Intelligent Tracking Prevention caps them at **7 days**, and as little as **24 hours** when the page was reached from a classified cross-site navigation.\n- Cookies written by the server in a `Set-Cookie` response header are not subject to that particular cap, which is a concrete architectural reason to set important cookies from the server rather than from script (on top of the fact that server-set cookies can be `HttpOnly`).\n\nThird-party (cross-site) cookies are a separate story again: increasingly blocked outright, so anything relying on them should already be re-architected.\n\n## 2. Eviction under limits\n\nBrowsers bound the cookie jar. The usual figures are around **180 cookies per domain**, a few thousand in total, and a per-domain byte cap (roughly 4 KB per cookie including attributes, plus an aggregate budget). When a limit is reached, the browser evicts — commonly the least-recently-used, sometimes preferring already-expired or non-secure entries.\n\nThe cruel part is the blast radius: limits are per *registrable domain*, so a marketing subdomain that writes 150 tracking cookies can push your carefully-set preference cookie out of the jar. Every cookie you add is a small tax on every other cookie on the domain, and on the size of every single request you send.\n\n## 3. User, policy and mode\n\nUsers clear browsing data; browsers offer "clear cookies on exit"; enterprise policy and antivirus "privacy cleaners" wipe jars on a schedule; private/incognito windows keep a separate jar destroyed on close; a profile switch or a second device has no shared jar at all. None of these is exotic.\n\n## 4. Storage pressure and corruption\n\nUnder disk pressure or after an unclean shutdown, browsers may discard part of the cookie store. Rare, but it happens, and it happens most to the users with the oldest, fullest devices.\n\n## Designing for a lossy store\n\n**Server-side truth.** The cookie holds an opaque identifier; everything meaningful lives server-side under that key. Losing the cookie then costs a re-login or a reset to defaults, never data.\n\n**Sliding refresh.** Re-send `Set-Cookie` with a fresh `Max-Age` on responses (or periodically, to avoid a header on every response). Active users keep a rolling window and never trip the absolute cap; inactive ones age out, which is usually what you wanted anyway.\n\n**Budget the jar.** One cookie, not eight. Do not shard preferences across cookies; store an ID and keep the payload on the server. Keep cookies small — they are sent on *every* matching request, so a 3 KB cookie is a permanent upload tax on your own latency as well as an eviction risk.\n\n**Scope narrowly.** Setting `Domain=example.com` shares your cookie with every subdomain and drags it into their requests; host-only cookies keep the blast radius small in both directions.\n\n**Absence is a normal state.** Every read path needs a default. "Cookie missing" means anonymous, or default theme, or re-authenticate — never a 500, never a broken page, never lost user work.\n\n**Fallbacks, chosen deliberately.** `localStorage` survives some cookie clearing but not most privacy clearing, is origin-scoped, is not sent automatically, and is readable by script — so it is fine for a UI preference and wrong for a credential. Server-side per-account preferences are the durable answer for signed-in users.\n\n**Measure it.** Instrument the rate of requests arriving without the cookie that you would have expected to have one. It is the only way to tell a browser policy change from a bug in your own code, and the number moves whenever a browser ships a new privacy release.