Frontend · interactive

Browser storage

Browsers offer five places to keep data. They differ in size, lifetime, whether they're sent to the server, and whether scripts can read them. That last one matters most for security. Pick what you're storing.

	size	sent to server	API	readable by JS	lasts
Cookies	~4 KB each	with every request	sync (document.cookie)	can be hidden (HttpOnly)	until expiry
localStorage	~5 MB	never	sync	always readable by JS	until cleared
sessionStorage	~5 MB	never	sync	always readable by JS	until the tab closes
IndexedDB	hundreds of MB+	never	async	always readable by JS	until cleared or evicted
Cache API	large	never	async (service workers)	readable by JS	until cleared or evicted

An HttpOnly, Secure, SameSite cookie is sent automatically and can't be read by injected scripts. Never put tokens in localStorage.

You need to store

Step 1 of 4 · read left to right

1
Secrets don't belong where scripts can read them
Any XSS can read localStorage. HttpOnly cookies are invisible to JavaScript.
Set-Cookie: sid=…; HttpOnly; Secure; SameSite=Lax
2
localStorage and sessionStorage
Simple string key-value stores. Synchronous, so keep them small.
Wrap access in try/catch: private modes can throw.
3
IndexedDB for lots of structured data
Async, indexed, transactional. Use a wrapper like idb or Dexie.
Ask navigator.storage.persist() to avoid eviction.
4
Cache API with a service worker
Store whole responses so the app loads offline.
Workbox simplifies strategies.

In production

Tools and technologies

Every web app stores something in the browser.

Not tied to one language — use these names when you search docs or design a system.