Lesson 0001 · ~10 minutes

When sessionStorage fits (and when it doesn’t)

One skill: place sessionStorage on the client storage spectrum and pick it only when the hard problem is small, string-shaped state that must stay in this tab for the page session.

Glossary Resources Mission

Win for this lesson

After the quiz, you can defend “sessionStorage yes / no” in a design review without writing a line of setItem yet — and without confusing it with localStorage, memory, or IndexedDB.

1. The problem sessionStorage solves

Sometimes state should survive a reload in this tab, but must not leak into another tab of the same site. Classic example from the HTML Standard: buying plane tickets in two windows at once. If you stash “which booking am I on?” in a shared cookie or localStorage, the two flows can cross-contaminate.

sessionStorage is the browser’s built-in answer for a page session: a small string key/value map scoped to the origin + this tab. It survives reloads and restores in that tab; closing the tab ends the session and clears the data (MDN).

It is part of Web Storage (with localStorage). Same simple Storage API — different lifetime and partition.

2. Not localStorage, and not a database

Two confusions that cause bad design reviews:

Not “localStorage that expires soon.” localStorage is shared by every same-origin tab and outlives browser restarts. sessionStorage is per-tab and dies with the tab. That is the product feature — isolation — not a weaker form of permanence (MDN Web Storage).
Not a general client database. Values are strings only, the API is synchronous (blocks the main thread), practical size is on the order of ~5 MB, and there is no access from web workers or service workers (web.dev. Structured, large, or off-main-thread data belongs in IndexedDB (or OPFS for files, Cache API for HTTP resources).

Mental model: sessionStorage is a tab-private sticky note for small strings — not a vault for auth tokens, not an offline entity store.

3. The client storage spectrum (sessionStorage highlighted)

Same map as your IndexedDB / Cache / OPFS tracks — from Storage for the web. Today the spotlight is the sessionStorage row.

Memory only

Component/module state. Fastest. Dies on refresh. Default when re-fetch or re-derive is cheap.

sessionStorage

Tab-scoped string map; survives reloads in that tab only. Sync API; tiny; not for workers. Prefer for short multi-step UI in one tab.

localStorage

Origin-scoped string map that persists across visits/tabs. Sync; tiny; no workers. Prefer for tiny durable prefs — not bulk data.

Tiny values often sent on every HTTP request. Auth/session use-cases with care — not a general client database.

IndexedDB

Large structured app data: drafts, entity caches, offline queues. Async; keys + indexes; works off-main-thread.

Cache API

Request/Response pairs for load/offline shells — not wizard form fields.

OPFS

File-shaped bytes on an origin-private filesystem. Editors and media pipelines — not a few UI flags.

Default rule (steal this)

If the hard part is “keep a small string (or JSON string) for this tab only, survive reload, forget when the tab closes”, start with sessionStorage. If the hard part is “remember across visits and tabs”, that is localStorage (still only for tiny strings) or a real store. If the hard part is “structured / large / async / workers”, use IndexedDB (or OPFS / Cache for their jobs). If re-fetch is fine, prefer memory only.

Signal	Leans sessionStorage	Leans away
Lifetime	This tab only; die on close; OK after reload	Survive restart; share every tab; permanent prefs
Isolation	Parallel tabs must not share the same draft/flow	Need multi-tab sync of the same key
Shape / size	Strings or small JSON; well under a few MB	Large lists, binary blobs, searchable records
Threading	Main-thread only; cheap occasional reads/writes	Hot path thrashing; worker must own the data
Classic fits	Multi-step wizard step index, one-tab form autosave, “dismissed this banner for now”	Theme across visits, offline entity cache, access tokens, app shell JS

FE integration difficulty (honest preview)

setItem is easy. What bites later: sync main-thread cost if abused, string-only serialization (JSON copies, not live objects), opener copy when using window.open, storage events that do not cross tabs for sessionStorage, and security mistakes (tokens in Web Storage are XSS loot). We’ll drill API + events later. Today: know the isolation story so you don’t oversell “just use sessionStorage.”

4. Practice — pick the store

Choose the best default. Equal-length options so formatting doesn’t hint. Feedback is immediate.

Scenario A

Checkout wizard: 4 steps in one tab. User may open a second checkout tab in parallel; flows must not overwrite each other. Reload mid-flow should restore the step.

Scenario B

Settings: remember light/dark theme across browser restarts and every tab. One string; slightly delayed apply is fine.

Scenario C

Notes app: multi-paragraph drafts and a list of thousands of note metadata objects must work offline and open in any tab.

Scenario D

Internal admin: always online; table of 20 rows from REST; no offline requirement; full refresh is acceptable.

Scenario E

Auth: store a long-lived API access token so SPA requests can attach Authorization headers after refresh.

5. What to remember

sessionStorage = origin + tab string map for the page session (survives reload; dies on tab close).
Use it for isolation (parallel tabs / multi-step flows), not as “temporary localStorage.”
Still Web Storage: sync, strings, small, no workers — web.dev’s “use with caution” bucket.
Prefer memory when re-fetch is fine; IDB/Cache/OPFS for real durable or large data; never treat Web Storage as a secret vault.

Ask your teacher Anything fuzzy — opener tabs, private mode, a wizard on your team, token debates — ask in chat. Follow-up questions are part of the method, not a distraction.

Primary source (read next)

MDN — Window.sessionStorage. Best short primary for this lesson’s lifetime and tab-partition rules (page session, reload, close, opener copy). Skim web.dev — Storage for the web if you want the spectrum defaults refreshed against IDB / Cache / OPFS.