Your half-finished checkout form does not belong in localStorage

A multi-step checkout holds its state in `useState`, the payment provider bounces the customer out to a 3-D Secure page and back, and the wizard returns on step one with an empty form, because `useState` lives exactly as long as the component instance and a reload or full-page navigation ends it ^[1][2]. The reflexive fix is `localStorage`, and it is the wrong default: according to a dev.to write-up on the `useSessionStorage` hook, the half-finished checkout then appears in every tab the customer has open, is still sitting there next week, and if they open two tabs to compare shipping options a `localStorage`-backed hook syncs the two forms into each other ^[3].

What `sessionStorage` scopes to is one top-level browsing context, meaning a tab or window, for one origin. It does not mean a logged-in session and it does not mean a browser session, which is where the name misleads people ^[4]. That lifetime is the one a wizard wants: state survives this tab's reloads, a redirect out to a payment provider and back, and the browser's back button, then disappears when the tab closes ^[5].

The heuristic in the post is worth stealing verbatim. If two tabs showing different values would be a bug, use `localStorage`; if two tabs showing the same value would be a bug, use `sessionStorage` ^[6]. Theme, language and a "don't show this again" dismissal are expected to be one value everywhere, so local ^[7]. A half-completed form, the filters on this dashboard view, and the page you were on before an auth redirect belong to one tab, so session ^[8].

Per-tab is not airtight, and the exceptions are worth knowing before you rely on the isolation. `window.open()` copies the opener's `sessionStorage` into the new window whenever that window keeps an `opener`, per the HTML spec, and Chrome's Duplicate tab copies it too; it is a one-time snapshot rather than a live link, so the two diverge from then on ^[9]. Modern browsers open `target="_blank"` links with `noopener` by default, so ordinary links start clean ^[10]. Same-origin iframes in the same tab do share it, since they sit in the same browsing context group, and that is the only place the browser's native `storage` event means anything for `sessionStorage` ^[11]. Two documented holes, both of them copy-on-open or same-tab, neither of them the live cross-tab sync that `localStorage` gives you for free ^[12].

Everything else is the same contract as `localStorage`: synchronous, string-only, roughly 5 MB per origin, and readable by any script on the page, so it is not a security boundary ^[13]. The shorter life limits the blast radius of a leak, but XSS reads it just as easily, and anything that must be secret from JavaScript belongs in an `httpOnly` cookie ^[14].

The article is, in fairness, a pitch for `useSessionStorage` from `@reactuses/core`, which returns the same `[value, setValue]` tuple as `useState`, reads on mount, writes on every update, and types the value `T | null` because `setValue(null)` removes the key ^[15]. Its more useful admission is that the hook shares its API, serialization and internals with `useLocalStorage`, so swapping the import changes the lifetime and nothing else ^[16]. The migration cost of getting this right is one line, which removes the usual excuse for not deciding.

Worth checking: your existing `localStorage` keys, for anything that is per-flow rather than per-user. And if you hand-roll the hook rather than take the dependency, the post flags hydration, tab restore and `window.open` as the cases that bite ^[17].