Browser Storage: Cookies, SessionStorage, LocalStorage, IndexedDB
Each browser storage mechanism solves a different problem. Understanding their persistence model, size limits, security risks (especially XSS), performance characteristics, and server accessibility is critical for making correct architectural decisions.
Cookies = a safe the hotel front desk (server) can also open. sessionStorage = a temporary locker in one changing room (tab). localStorage = your personal locker that survives visits. IndexedDB = a large bank vault with organized drawers (indexes) for big or complex belongings.
2sessionStorage
Per-tab, temporary storage cleared when the tab is closed. Not shared across tabs. Perfect for multi-step wizards, form drafts, or temporary UI state.
3localStorage
Persistent across browser sessions, domain-scoped, synchronous API. Great for user preferences (theme, language) but vulnerable to XSS and blocks the main thread on large operations.
4IndexedDB
A full-featured client-side database with transactions, indexes, and large storage capacity. Asynchronous API. Ideal for offline-first applications, large datasets, and complex querying.
5Security & XSS Risks
All client-side storage (localStorage, sessionStorage, IndexedDB, non-httpOnly cookies) can be read and modified by malicious JavaScript. Always store authentication tokens in httpOnly cookies and enforce strong CSP.
| Property | Cookies | sessionStorage | localStorage | IndexedDB |
|---|---|---|---|---|
| Security | High (with httpOnly) | Medium (XSS risk) | Medium (XSS risk) | Medium (XSS risk) |
| Size Limit | ~4KB | ~5-10MB | ~5-10MB | Hundreds of MB |
| Performance | Sent on every request | Synchronous | Synchronous | Asynchronous |
| Persistence | Configurable | Tab session only | Across sessions | Across sessions |
| Server Access | Yes | No | No | No |
Cookies
Security
High (with httpOnly)
Size Limit
~4KB
Performance
Sent on every request
Persistence
Configurable
Server Access
Yes
sessionStorage
Security
Medium (XSS risk)
Size Limit
~5-10MB
Performance
Synchronous
Persistence
Tab session only
Server Access
No
localStorage
Security
Medium (XSS risk)
Size Limit
~5-10MB
Performance
Synchronous
Persistence
Across sessions
Server Access
No
IndexedDB
Security
Medium (XSS risk)
Size Limit
Hundreds of MB
Performance
Asynchronous
Persistence
Across sessions
Server Access
No
Common questions
- ›“When would you use localStorage vs IndexedDB?”
- ›“Why should auth tokens never be stored in localStorage?”
- ›“What are the security risks of each storage type?”
- ›“How do you choose the right storage mechanism for a feature?”
What interviewers look for
- Strong security awareness (httpOnly cookies for tokens)
- Clear understanding of persistence, size, and performance trade-offs
- Knowledge of XSS risks and mitigation strategies (CSP)
- Practical decision-making based on use case
Short answer (60 sec)
Cookies for server-accessible auth (httpOnly). sessionStorage for temporary tab data. localStorage for simple persistent preferences. IndexedDB for large, structured, or offline data. Never store sensitive tokens in client-side storage.
Detailed answer (senior level)
Each storage has a purpose: Cookies enable server access and strong security when httpOnly. sessionStorage is isolated per tab. localStorage persists but is synchronous and vulnerable to XSS. IndexedDB provides large capacity and powerful querying but requires an async API. Choose based on persistence needs, data size, security sensitivity, and whether server access is required. Always protect auth tokens with httpOnly cookies and implement CSP.
- Storing JWT/auth tokens in localStorage
- Using localStorage for large or frequently read data
- Blocking the main thread with synchronous storage operations
- Not handling quota exceeded errors gracefully
- Assuming data in localStorage is private or secure
- ✓Cookies are the only storage sent to the server automatically
- ✓httpOnly + Secure + SameSite cookies are required for authentication
- ✓localStorage and sessionStorage are synchronous and XSS-vulnerable
- ✓IndexedDB is the best choice for large or offline-first applications
- ✓Never store sensitive data in client-side storage
- ✓Layer storage solutions based on specific requirements
- ✓Always consider security, performance, and persistence trade-offs