In this chapter
We'll meet sessionStorage — the same API as localStorage, but scoped to a single tab and erased when that tab closes — and use it to fully resolve GreenMart's own lost-cart incident: the cart was never written anywhere durable at all.
The Problem in Real Life
"Before we pick localStorage for the cart," Sarah says, "there's a real, separate question underneath it: should a cart survive someone closing the browser entirely and coming back next week? Or should it just survive a refresh, within the same visit?"
Mike thinks about it. "Honestly... probably just the visit. If they come back next week, prices might have changed anyway."
I don't actually know if I want the cart to last forever. Maybe I don't.
Mike
Surviving a Browser Restart vs. Surviving Only the Current Tab
Gone on tab close, not just on request
sessionStorage survives a refresh but is automatically erased the moment its specific tab or window closes — no explicit clear() needed.
Isolated per tab, even for the same origin
Two tabs open to the identical site get two completely separate sessionStorage buckets — a real guarantee localStorage doesn't offer.
sessionStorage
sessionStorage shares localStorage's exact API — setItem, getItem, removeItem, clear, string-only values — but answers a genuinely different real question about lifetime and scope. Where localStorage asks "how do I persist data across restarts," sessionStorage asks "how do I keep data for just this one browsing session, and only this one."
- Lifetime: gone when the tab closes. Data written to sessionStorage survives a page refresh and normal navigation within the same tab, but is genuinely erased the moment that specific tab or window is closed — no explicit
clear()call needed, the browser does it automatically. This is a real, deliberate trade against localStorage's indefinite persistence, for data that genuinely shouldn't outlive the visit it was created in. - Scope: isolated per tab, not just per origin. This is the real, easy-to-miss distinction from localStorage: open the same site in two separate tabs, and each tab gets its own completely separate sessionStorage, even though both are the exact same origin. localStorage, by contrast, is shared across every tab open to the same origin. A multi-step checkout form filled out in one tab genuinely won't leak into or be overwritten by a second tab open to the same site — a real, useful isolation guarantee localStorage can't offer.
- The honest, most likely real diagnosis of GreenMart's lost cart. Given the symptom — gone on a plain refresh, within the same tab, same visit — the cart almost certainly wasn't in sessionStorage either. sessionStorage explicitly survives a refresh; only a full tab close erases it. The real, most likely cause, now fully resolvable: the cart was living purely in the page's own in-memory JavaScript state (a plain variable), which a refresh restarts completely, exactly as Act 1's volatile-storage chapter described — never written to sessionStorage, localStorage, or anywhere else durable at all.
This is a genuinely useful, closing piece of the diagnosis: GreenMart never even reached the "which persistent option is right" question, because nothing was persisted at all. Now, with both real options named and understood, that choice can actually be made on purpose.
Key Takeaway
sessionStorage and localStorage share an API but answer different real questions — how long should this survive, and how isolated should it be per tab — and naming both precisely is what finally, fully explains why a plain refresh emptied GreenMart's cart.
Why This Matters
Choosing between localStorage and sessionStorage isn't a technical detail — it's a real product decision about what a customer should reasonably expect a cart, a draft, or a form to do when they close a tab or come back later. Getting it right on purpose, instead of by accident, is the actual fix for GreenMart's incident.
GreenMart now has the full, real diagnosis: the cart was never written anywhere durable at all — purely in-memory, gone on any refresh. Both real fix candidates (localStorage, sessionStorage) are now understood well enough to choose between deliberately. The next chapter turns to a genuinely different kind of browser storage — one built for structured, queryable data at real scale: IndexedDB.