localStorage / sessionStorage vs Cookies
Side-by-side comparison, when-to-use-each guide, and instant conversion. Reviewed for 2026.
User preferences, draft content, client-side caches, anything the server doesn't need.
Authentication (HttpOnly), CSRF tokens, anything the server reads on every request.
| Aspect | localStorage / sessionStorage | Cookies |
|---|---|---|
| Size limit | 5-10 MB | 4 KB |
| Sent with each request | No | Yes |
| JS access | Yes | Yes (unless HttpOnly) |
| Server access | No (client only) | Yes (every request) |
| Cross-domain | No | Possible (with proper config) |
Frequently asked
Why not use localStorage for auth tokens?
localStorage is readable by any JavaScript on the page — including injected XSS attacks. HttpOnly cookies can't be read by JS, so an XSS bug can't steal them. For auth, always use HttpOnly cookies, never localStorage.
What about IndexedDB?
IndexedDB is a much larger client-side database (~50% of free disk by default, often GB). Use it for substantial client-side data (offline apps, image caches). For simple key-value, localStorage is enough.
Frequently asked questions
Why not use localStorage for auth tokens?
localStorage is readable by any JavaScript on the page — including injected XSS attacks. HttpOnly cookies can't be read by JS, so an XSS bug can't steal them. For auth, always use HttpOnly cookies, never localStorage.
What about IndexedDB?
IndexedDB is a much larger client-side database (~50% of free disk by default, often GB). Use it for substantial client-side data (offline apps, image caches). For simple key-value, localStorage is enough.