Compare Browser Storage Mechanisms

Interview Question: "What are the different browser storage options? When would you use each?"

The Senior Answer

Don't just list them. Show you understand the constraints that drive the choice:

"The browser has five storage mechanisms, each optimized for different constraints — capacity, persistence, server visibility, and sync vs async access. The choice depends on what you're storing, who needs to read it, and how much of it there is."

The Quick Comparison

The Decision Framework

"I think about it as a decision tree:

Does the server need to read it? → Cookie (only storage sent automatically with requests)

Is it an auth token? → HttpOnly Secure SameSite cookie (not accessible to JS, immune to XSS)

Is it small, client-only data? → localStorage (persists) or sessionStorage (tab-only)

Is it a large or structured dataset? → IndexedDB (async, indexed, can hold hundreds of MB)

Is it cached HTTP responses? → Cache API (designed for request/response pairs, used with Service Workers)"

Follow-Up Questions

"Where should I store JWT tokens?"

"This is a loaded question with a nuanced answer:

Option 1: HttpOnly cookie (recommended for web apps) — Not accessible via JavaScript, so XSS can't steal it. Requires CSRF protection (SameSite attribute + CSRF tokens).

Option 2: In-memory variable — Immune to both XSS (not persisted) and CSRF (not sent automatically). Downside: lost on page refresh. Solve with a refresh token in an HttpOnly cookie.

Option 3: localStorage (common but risky) — Any XSS vulnerability gives the attacker full access to the token. Convenient but insecure.

The right answer depends on your threat model. For most web apps, HttpOnly cookie + SameSite is the safest default."

"Why is localStorage synchronous a problem?"

"localStorage operations block the main thread. Reading and parsing a 5MB JSON string is synchronous — the UI freezes until it completes. On a low-end mobile device, this can be 100ms+ of jank. For large data, IndexedDB's async API prevents this. For small data (a few KB of preferences), localStorage is fine."

"How do you sync state across browser tabs?"

"localStorage fires a storage event in other tabs when a value changes. This is the simplest cross-tab communication:

window.addEventListener('storage', (e) => {
  if (e.key === 'theme') applyTheme(e.newValue);
});

For more complex scenarios, the BroadcastChannel API provides a publish/subscribe model across tabs, and SharedWorker maintains a single worker shared across tabs."

"What happens when storage is full?"

"Cookies: The browser silently drops the oldest ones (per domain). localStorage/sessionStorage: Throws a QuotaExceededError. IndexedDB/Cache API: Triggers the browser's storage eviction — the browser may clear data from the least-recently-used origin. You can check with navigator.storage.estimate() and request persistence with navigator.storage.persist()."

"Are cookies really sent with EVERY request?"

"Yes — every HTTP request to the matching domain and path, including images, CSS, fonts, API calls. This is why putting 200KB of data in cookies is a disaster — it adds 200KB of overhead to every single resource request. Keep cookies minimal; use localStorage or IndexedDB for client-only data."

Security Awareness

"All client-side storage except HttpOnly cookies is vulnerable to XSS — if an attacker injects script into your page, they can read localStorage, sessionStorage, and IndexedDB. HttpOnly cookies are the only storage invisible to JavaScript. This is why sensitive tokens belong in HttpOnly cookies, not localStorage."

The One-Liner

"Cookies are for the server, localStorage is for the client, sessionStorage is for the session, IndexedDB is for the database, and Cache API is for the network. Use the one that matches your constraint."

Red Flags

• Not knowing cookies are sent with every request
• Storing JWTs in localStorage without discussing the XSS risk
• Forgetting IndexedDB exists (it's the only option for large structured data)
• Not knowing sessionStorage is tab-scoped
• Treating all storage as interchangeable