sessionStorage
The exact same API as localStorage — scoped to one tab, gone the moment that tab closes.
Overview
sessionStorage shares the exact same key-value string API as localStorage — `setItem`, `getItem`, `removeItem`, `clear` — but with one deliberate difference: it's scoped to a single tab's lifetime instead of persisting indefinitely. Close that tab, and it's gone. Open the identical page in a new tab, and it starts completely empty, even for the exact same origin.
Why It Exists
Some state only matters for the duration of one browsing session in one tab — the in-progress answers of a multi-step form, a 'don't show this tooltip again this visit' flag, per-tab state in an app where a user might have several tabs of it open independently. Reaching for localStorage for that kind of state would leak it across every tab and every future visit, when the entire point was for it to disappear once that one tab was done. sessionStorage exists specifically to fill that gap without inventing a separate API.
Real World Example
A multi-step signup wizard saves each step's answers to sessionStorage as the user progresses, so refreshing the page mid-flow doesn't lose their progress. Close the tab and come back an hour later, though, and the wizard starts fresh — which is the correct behavior here, unlike a shopping cart, which usually should survive across visits and therefore belongs in localStorage instead.
How It Works
sessionStorage is exposed on `window.sessionStorage` with an identical method signature to localStorage, so any code already written against one works against the other by swapping the object. The real difference is scope: each tab (technically, each top-level browsing context) gets its own isolated sessionStorage area, even when two tabs are open to the exact same origin — a value set in one tab is invisible in the other. It survives a page reload within that same tab, but is destroyed the moment the tab closes.
Diagram
Scoped to one tab — a reload survives it, closing the tab doesn't
Tab opens
sessionStorage starts empty for this tab
Page calls setItem()
data stored for this tab only
Page reloads (same tab)
data survives
Tab closes
data is destroyed
Same site opened in a new tab
starts empty — sessionStorage isn't shared
Syntax
// Write
sessionStorage.setItem("wizardStep", "2");
// Read
const step = sessionStorage.getItem("wizardStep"); // "2" | null
// Remove one key
sessionStorage.removeItem("wizardStep");
// Remove everything for this tab
sessionStorage.clear();Methods
setItem(key, value)Stores a key-value pair for this tab. Both are coerced to strings.
getItem(key)Returns the string value, or null if the key doesn't exist in this tab.
removeItem(key)Deletes a single key-value pair from this tab's storage.
clear()Deletes every key-value pair for the current origin, in this tab only.
key(index)Returns the name of the key at a given numeric index — rarely used directly.
Common Mistakes
Expecting sessionStorage to be shared across multiple tabs of the same site
Why: Each tab gets its own isolated sessionStorage, even for the identical origin open in two tabs at once — a value set in one tab is simply invisible in the other.
Fix: Use localStorage if the value genuinely needs to be shared across tabs, or a mechanism like BroadcastChannel/storage events if tabs need to actively communicate.
Assuming reopening the browser always restores sessionStorage
Why: Some browsers restore tabs (and their sessionStorage) after a crash or an explicit 'reopen closed tab,' but this behavior isn't guaranteed consistently across browsers and shouldn't be designed around.
Fix: Treat sessionStorage as genuinely ephemeral — gone once the tab closes, full stop — rather than relying on any browser's session-restore behavior.
Using sessionStorage for data that should actually persist across visits
Why: Because the API is identical to localStorage, it's easy to grab the wrong one out of habit — data that should survive the user closing the tab (like a saved cart) silently vanishes if it's put in sessionStorage instead.
Fix: Choose based on one question: should this survive the tab closing? Yes → localStorage. No → sessionStorage.
Interview Questions
What's the core difference between sessionStorage and localStorage?
They share the exact same API. localStorage persists indefinitely until explicitly cleared; sessionStorage is destroyed as soon as the tab it belongs to is closed.
If a user opens the same website in two separate tabs, do those tabs share the same sessionStorage?
No. Each tab gets its own isolated sessionStorage, even for the identical origin. localStorage, by contrast, is shared across every tab open to that origin — that's the behavioral distinction that actually matters day to day, more than the persistence difference.
You need per-tab state that survives a page reload but not a tab close, and must never leak between two tabs of the same app open in parallel. What do you use, and why?
sessionStorage matches all three constraints directly: it survives a reload within the same tab, it's destroyed when that tab closes, and it's isolated per tab so two parallel tabs never see each other's values. In-memory JavaScript state would fail the reload requirement, and localStorage would fail the isolation requirement by leaking state across tabs.
Production Best Practices
Do
✓Use sessionStorage for state that's only meaningful for one tab's current visit, like in-progress form steps.
✓Choose between sessionStorage and localStorage based on whether the data should survive the tab closing — not out of habit.
✓Wrap calls in a try/catch, same as localStorage — quota and availability issues apply equally.
Don't
✗Don't expect sessionStorage to be shared between multiple tabs of the same origin.
✗Don't rely on any browser's session-restore behavior to bring sessionStorage back after a real tab close.
✗Don't use sessionStorage for anything the user would expect to still be there on their next visit.
Comparison
| sessionStorage | localStorage | |
|---|---|---|
| Persistence | Until the tab closes | Until explicitly cleared |
| Shared across tabs? | No — isolated per tab | Yes — shared across all tabs of the origin |
| Survives a page reload? | Yes (same tab) | Yes |
| Best for | Per-tab, in-progress state | State that should persist across visits |