Browser Storage: localStorage vs sessionStorage vs IndexedDB (When to Use Which)

Storage questions appear in interviews because they test whether you understand:

• persistence
• security (XSS)
• performance and data size

This guide gives you a clear decision framework.

30‑second interview answer

Use cookies for server-linked auth sessions (prefer HttpOnly). Use localStorage for small non-sensitive preferences (string-only, sync API, vulnerable to XSS). Use sessionStorage for per-tab temporary state. Use IndexedDB for large/offline/structured storage (async, powerful). Don’t store secrets in localStorage.

Key points

• Cookies are sent with requests; storage is client-only.
• localStorage/sessionStorage are synchronous and string-only.
• IndexedDB is async and suited for offline caches.
• XSS is the big risk for client storage.

1) The storage options in a browser

A) Cookies

• small (often ~4KB per cookie)
• automatically sent with HTTP requests (depending on domain/path)
• useful for auth sessions when HttpOnly

B) Web Storage

• localStorage (persistent)
• sessionStorage (tab/session scoped)
• string-only key/value

C) IndexedDB

• structured storage
• async
• large data support
• best for offline apps and caching

2) localStorage

What it is

• persistent key/value store
• survives tab close + browser restart

API

localStorage.setItem('theme', 'dark');
const theme = localStorage.getItem('theme');
localStorage.removeItem('theme');
localStorage.clear();

Key limitations

• values are strings only
• synchronous (can block main thread if abused)

Best for

• small preferences: theme, language
• tiny flags

Not good for

• tokens (security)
• large datasets

3) sessionStorage

What it is

• like localStorage, but scoped to a single tab/window session
• cleared when the tab is closed

Best for

• step-by-step flows (multi-step forms)
• “temporary state that should not persist forever”

4) IndexedDB

What it is

• a transactional database in the browser
• stores objects, blobs, files
• async (non-blocking)

When it shines

• offline-first apps
• caching API responses
• storing large lists
• saving files and blobs

Conceptual model

• database → object stores → indexes

Example (simplified):

// Usually you use a wrapper library like idb.
// Raw IndexedDB API is verbose.

Interview tip: Say that you’d use a wrapper like idb for ergonomics.

5) Security: the biggest trap (XSS)

Rule: never store secrets in localStorage

If an attacker gets XSS, they can read localStorage.

So access tokens in localStorage are high risk.

Safer approach for auth sessions

• store session in HttpOnly cookies
• use CSRF protections + SameSite settings

Interview-ready answer:

• localStorage is vulnerable to XSS exfiltration.

6) JSON patterns for Web Storage

Since storage is string-based:

function setJson(key, value) {
  localStorage.setItem(key, JSON.stringify(value));
}
 
function getJson(key, fallback) {
  const raw = localStorage.getItem(key);
  if (!raw) return fallback;
 
  try {
    return JSON.parse(raw);
  } catch {
    return fallback;
  }
}

7) Quotas & performance

• localStorage/sessionStorage quotas vary by browser
• IndexedDB is generally much larger
• localStorage is synchronous → avoid frequent writes in hot paths

8) Interview: decision table (in words)

• Cookies: auth sessions (HttpOnly), small server-coupled data
• localStorage: preferences, small client-only data
• sessionStorage: temporary per-tab flow state
• IndexedDB: offline caches, large structured data

9) Common interview questions

Q: localStorage vs cookies?

• cookies go to server automatically; localStorage is client-only.

Q: Why not store JWT in localStorage?

• XSS can steal it.

Q: What would you use for offline support?

• IndexedDB + Service Worker cache.

Summary checklist

• I know cookie vs storage differences.
• I can explain why localStorage is risky for JWT.
• I know when to choose IndexedDB.
• I mention XSS and HttpOnly in interviews.

Summary

• Use localStorage/sessionStorage for small, non-sensitive state.
• Use IndexedDB for serious storage (offline/cache/large data).
• Use HttpOnly cookies for auth sessions when possible.
• Always consider XSS risk.