In the browser, how do localStorage and sessionStorage differ in scope and lifetime, and what do the two have in common?

## One API, two containers Web Storage is defined by the HTML standard as a single interface, `Storage`, exposed twice on `window`: as `localStorage` and as `sessionStorage`. The methods are identical — `setItem(key, value)`, `getItem(key)`, `removeItem(key)`, `clear()`, `key(index)` and the `length` property — and both areas store only strings, synchronously, on the main thread. Every difference between them is about *which container* your call lands in, and *how long that container lives*. ## The origin is the boundary Both areas are partitioned by origin, meaning the triple of scheme, host and port. `https://example.com` and `http://example.com` are different origins, so they have different stores. `https://app.example.com` and `https://example.com` are different origins too — there is no equivalent of a cookie's domain attribute that lets a parent domain and a subdomain share one Web Storage area. Ports matter as well, which is why a dev server on `:3000` and one on `:5173` never see each other's data. ```js // on https://example.com localStorage.setItem('theme', 'dark'); // on https://app.example.com — a different origin, so: localStorage.getItem('theme'); // null ``` ## localStorage: origin-wide and effectively permanent `localStorage` has no expiry mechanism at all. There is no TTL parameter, no max-age, nothing analogous to a cookie's expiry. A value written once is still there after a reload, after the tab is closed, and after the browser is restarted. It disappears only when your code removes it, when the user clears site data, or when the browser evicts the origin's data under storage pressure. If you want expiring data you have to build it yourself — store a timestamp alongside the value and check it on read. Its other defining property is that it is shared by every tab, window and same-origin iframe of that origin in the same browser profile. Two tabs open on your app are looking at one store, which is exactly why the `storage` event exists to tell the other tabs that something changed. ## sessionStorage: one tab, one store `sessionStorage` is scoped to a tab's top-level browsing context. Inside that tab it is quite durable: it survives a reload, a hard reload, and navigations to other pages of the same origin. It does *not* travel to a second tab — open your site in a new tab manually and its `sessionStorage` starts empty. A same-origin iframe inside the tab shares the tab's session store; a cross-origin iframe gets its own, keyed by its own origin. One detail people get wrong: browsers clone the session store into an auxiliary tab opened *from the page*, for example by `window.open()` or a link with `target="_blank"`. It is a copy, not a live link — writes afterwards do not propagate between the two tabs. When the tab is closed the store is dropped, although browsers that offer "reopen closed tab" or session restore usually bring it back with the tab. ## Choosing between them Ask whether the data describes *this tab* or *this user on this site*. Wizard progress, a scroll position for the current view, a "you are acting as account X in this tab" selection, a one-time redirect target captured before login — all of those are per-tab and belong in `sessionStorage`, where a second tab correctly starts fresh. Theme preference, a dismissed-banner flag, a cached list you would rather not refetch, a feature-flag snapshot — those describe the user on the origin and belong in `localStorage`. ## What they share, and what that costs Because both are the same interface, both inherit the same constraints. Values and keys are strings, so anything structured has to be serialised by you. Access is synchronous and blocks the main thread. Neither object exists in a `Worker` scope, so a worker that needs persistence uses IndexedDB or the Cache API instead. Both live under a modest per-origin limit — commonly around 5 MB, exact figure browser-dependent — and both throw when that limit is hit. And in a private/incognito window the browser gives the origin a separate ephemeral store that is discarded when the private session ends, so nothing written there survives. ## The usual interview traps "sessionStorage clears on reload" is wrong — only closing the tab clears it. "localStorage is shared across subdomains" is wrong — that is cookie behaviour. "localStorage expires after a while" is wrong — it has no expiry, only eviction. And "I'll read it from my worker" does not compile, because the property is not there.