Browsers offer multiple mechanisms for persisting data on the client or server side. Cookies, localStorage, and sessions each serve different purposes, have different lifetimes, and carry distinct security implications that every web developer must understand.
Cookies are small key-value strings (up to ~4 KB) stored by the browser and automatically attached to every HTTP request sent to the matching domain. They are set via the Set-Cookie response header from the server or via document.cookie in JavaScript. Cookies support expiration dates, making them suitable for both session-length and long-lived storage. Because they travel with every request, they are the standard vehicle for authentication tokens and server-side session identifiers.
localStorage is a browser-native Web Storage API that stores string key-value pairs (up to ~5–10 MB) permanently on the client's device with no automatic expiration. Data persists across browser tabs and restarts until explicitly cleared via JavaScript or the user purges browser data. Unlike cookies, localStorage data is never automatically sent to the server — you must read it in JavaScript and include it manually in requests. It is best suited for UI preferences, cached data, or offline-capable app state.
A server-side session is a data store (in memory, a database, or a cache like Redis) that holds user-specific state keyed by a unique session ID. The session ID alone is sent to the client, typically inside a cookie, so sensitive data never leaves the server. When a request arrives, the server looks up the session ID, retrieves the associated data, and processes the request accordingly. This model keeps payloads small and lets the server invalidate sessions instantly without touching the client.
Cookies can be session-scoped (deleted on browser close) or persistent (via Expires/Max-Age). localStorage persists indefinitely until cleared. Session data lives only as long as the server keeps it alive, regardless of what the client holds. Cookies are scoped by domain and path; localStorage is scoped strictly by origin (scheme + host + port); server sessions are scoped by whatever the server associates with the ID.
Cookies should be flagged HttpOnly (blocks JavaScript access, mitigating XSS theft) and Secure (HTTPS only); the SameSite attribute guards against CSRF attacks. localStorage is fully accessible to JavaScript, making it a high-value XSS target — never store auth tokens there. Session IDs must be long, random, and regenerated on privilege changes (e.g., login) to prevent session fixation attacks. Always use HTTPS regardless of which storage mechanism you choose.
Use HttpOnly cookies to store session IDs or short-lived auth tokens because the browser manages transmission and HttpOnly prevents script access. Use localStorage for non-sensitive, client-only state like theme preferences or draft content that needs to survive page reloads. Use server-side sessions when you need to store sensitive or large per-user data and want centralized revocation control. For modern auth, consider short-lived JWTs in HttpOnly cookies combined with server-side refresh-token records for the best balance of statelessness and security.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app