Cookies vs localStorage

What is an HTTP cookie?

A cookie is a small piece of data the server sends to the browser via the Set-Cookie response header. The browser stores it and includes it automatically in subsequent requests to the same origin via the Cookie request header. This automatic transmission is what makes cookies essential for session management — the server can identify the user without them re-sending credentials on every request.

Cookies carry optional attributes that control their security and lifetime:

• HttpOnly — prevents JavaScript from reading the cookie. An attacker who injects malicious JavaScript cannot exfiltrate an HttpOnly cookie. Always set this on authentication cookies.
• Secure — the cookie is only transmitted over HTTPS. Prevents interception on unencrypted connections.
• SameSite=Strict — the cookie is never sent on cross-site requests, blocking CSRF attacks entirely. Use Lax if you need the cookie sent on top-level cross-site navigations (e.g. clicking a link from another site).
• Domain — controls which (sub)domains receive the cookie. Domain=example.com sends the cookie to all subdomains.
• Path — restricts the cookie to a URL path prefix; Path=/api stops the cookie being sent on asset requests.
• Expires / Max-Age — sets an absolute or relative expiry. Without either, the cookie is a session cookie and is removed when the browser closes.

# Server sets a secure auth cookie
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Strict; Max-Age=604800; Path=/

What is localStorage?

localStorage is part of the Web Storage API (alongside sessionStorage). It is a simple key-value store accessible via JavaScript on the same origin. Data is persisted across browser sessions — it survives page refreshes, tab closes, and even browser restarts — until explicitly removed.

Unlike cookies, localStorage is never sent to the server. This makes it suitable for large client-side data such as cached JSON responses, user preference objects, or offline application state, but unsuitable for anything the server needs to read (such as session identifiers or CSRF tokens).

The API is synchronous — reading or writing large objects blocks the main thread — so prefer IndexedDB for large or structured datasets.

// Storing and reading a preference
localStorage.setItem('theme', 'dark');
const theme = localStorage.getItem('theme'); // 'dark'

// Objects must be serialised to JSON — localStorage only stores strings
const prefs = { fontSize: 16, sidebar: true };
localStorage.setItem('prefs', JSON.stringify(prefs));
const loaded = JSON.parse(localStorage.getItem('prefs') ?? '{}');

// Clearing a single key or all data
localStorage.removeItem('theme');
localStorage.clear();

Security deep-dive: XSS and CSRF

The choice between cookies and localStorage is ultimately a security trade-off between two attack types: XSS (Cross-Site Scripting) and CSRF (Cross-Site Request Forgery).

XSS allows an attacker to run JavaScript in a victim's browser. Any data in localStorage or a non-HttpOnly cookie can be read and sent to the attacker's server. HttpOnly cookies are immune to this — the browser simply refuses to expose them to JavaScript.

CSRF tricks the victim's browser into making an authenticated request to your server (e.g. by loading a malicious page that submits a form). Because browsers attach cookies automatically, a cookie-authenticated endpoint is vulnerable unless SameSite protection is in place. localStorage values are never sent automatically, so CSRF is not a concern for localStorage-based auth — but this only helps if your frontend explicitly includes the token in every request header, which still requires correct API design.

// Sending a localStorage JWT manually in every request
const token = localStorage.getItem('access_token');
const response = await fetch('/api/profile', {
  headers: {
    'Authorization': `Bearer ${token}`,
  },
});

The modern consensus for web applications is: store authentication tokens in HttpOnly, Secure, SameSite=Strict cookies, pair with a strict Content Security Policy, and use anti-CSRF tokens or the Double Submit Cookie pattern if SameSite=Lax is required for cross-site flows.

Code examples

Setting a cookie from the server (Node.js / Express)

res.cookie('session_id', token, {
  httpOnly: true,    // not accessible to JavaScript
  secure: true,      // HTTPS only
  sameSite: 'strict', // no cross-site sending
  maxAge: 7 * 24 * 60 * 60 * 1000, // 7 days in ms
  path: '/',
});

Reading a cookie in the browser (non-HttpOnly)

// document.cookie returns a semicolon-separated string
const getCookie = (name) => {
  const match = document.cookie.match(new RegExp(`(?:^|; )${name}=([^;]*)`));
  return match ? decodeURIComponent(match[1]) : null;
};

const lang = getCookie('preferred_lang'); // e.g. 'en-GB'

localStorage with expiry simulation

// localStorage has no native expiry — implement it manually
function setWithExpiry(key, value, ttlMs) {
  const item = { value, expiry: Date.now() + ttlMs };
  localStorage.setItem(key, JSON.stringify(item));
}

function getWithExpiry(key) {
  const raw = localStorage.getItem(key);
  if (!raw) return null;
  const item = JSON.parse(raw);
  if (Date.now() > item.expiry) {
    localStorage.removeItem(key);
    return null;
  }
  return item.value;
}

setWithExpiry('cache_key', { data: [] }, 60_000); // 1 minute TTL