sessionStorage, IndexedDB, and Choosing the Right API

sessionStorage exposes the exact same methods as localStorage but its lifetime is tied to the tab. When the tab or window closes, its data is cleared automatically.

It is also isolated per tab, so two tabs do not share sessionStorage data.

sessionStorage shines for a multi-step wizard where you want to preserve progress across reloads within the session but discard it once the tab closes.

The user can refresh mid-form without losing entries, yet nothing lingers after they finish or leave.

IndexedDB is an asynchronous, transactional database built into the browser. It can store far more than localStorage 5MB limit and handles structured objects, arrays, and even binary data.

Because it is async, it does not block the main thread like localStorage does.

The raw IndexedDB API is verbose and event-based, so libraries like idb-keyval wrap it in simple Promise-based functions such as get, set, and del.

This gives you localStorage-like ergonomics with IndexedDB capacity and async behavior.

Because IndexedDB can store Blob and ArrayBuffer values, it is ideal for caching images, audio, downloaded files, or offline assets.

These would quickly blow past localStorage limits and would have to be stringified, which IndexedDB avoids.

The Cache API, often used with service workers, stores whole HTTP Response objects keyed by request. It is purpose-built for offline-first caching of network responses.

Use it to serve assets and API responses without hitting the network when offline.

localStorage persists permanently until cleared, sessionStorage lasts only for the tab session, IndexedDB persists permanently, and cookies have configurable expiry via their attributes.

Matching the lifetime you need to the right store avoids surprises about when data disappears.

localStorage and sessionStorage are limited to roughly 5MB, cookies to about 4KB each, while IndexedDB can use hundreds of megabytes or more depending on the device and browser.

For anything sizable, IndexedDB is the only practical browser option.

localStorage, sessionStorage, and cookies are synchronous, blocking the main thread during access. IndexedDB and the Cache API are asynchronous and Promise-based.

Async access keeps the UI responsive even when reading or writing larger amounts of data.

Use httpOnly cookies for auth tokens so scripts cannot read them, localStorage for small persistent preferences, IndexedDB for large files and complex offline data, and sessionStorage for short-lived drafts within a tab.

Match the store to the data sensitivity, size, and lifetime.

There is no single best storage API; each trades off capacity, persistence, sync behavior, and security. Knowing their differences lets you pick deliberately.

A typical app uses several: cookies for auth, localStorage for prefs, and IndexedDB for offline assets.

Test your understanding of storage choices.

You compared sessionStorage, localStorage, IndexedDB, cookies, and the Cache API across persistence, capacity, sync behavior, and security.

You learned to choose by use case: cookies for auth, localStorage for small prefs, IndexedDB for large or complex data, and sessionStorage for tab-scoped drafts.