sessionStorage vs localStorage vs cookies

All three are client-side storage mechanisms, but they differ in lifetime, scope, size limits, and whether data is sent to the server. localStorage persists until explicitly cleared, sessionStorage lasts only for the browser tab's lifetime, and cookies are sent with every HTTP request to the server and can have expiration dates. Choosing the right one depends on whether you need persistence, server access, or tab isolation.

localStorage stores key-value pairs that persist indefinitely — they survive page refreshes, browser restarts, and even system reboots. Data is scoped to the origin (protocol + domain + port) and shared across all tabs and windows on that origin. It's the go-to for data that should persist between sessions.

// Store data — persists until explicitly removed
localStorage.setItem('theme', 'dark');
localStorage.setItem('user', JSON.stringify({ name: 'Alice', id: 42 }));

// Retrieve data
const theme = localStorage.getItem('theme'); // 'dark'
const user = JSON.parse(localStorage.getItem('user') ?? '{}');

// Remove specific item
localStorage.removeItem('theme');

// Clear everything for this origin
localStorage.clear();

// Storage limit: ~5-10MB per origin (varies by browser)

sessionStorage has the same API as localStorage, but data only lasts for the duration of the page session — when the tab or window is closed, the data is gone. Each tab gets its own isolated storage, even for the same origin. This makes it perfect for data that should be tab-specific and temporary.

// Store data — cleared when tab closes
sessionStorage.setItem('currentStep', '3');
sessionStorage.setItem('formDraft', JSON.stringify({ name: 'Bob' }));

// Same API as localStorage
const step = sessionStorage.getItem('currentStep'); // '3'

// Key difference: tab isolation
// Tab A: sessionStorage.setItem('cart', '[...]')
// Tab B: sessionStorage.getItem('cart') → null (different session)

// Storage limit: ~5-10MB per origin per tab

Cookies are the oldest storage mechanism and the only one that's automatically sent to the server with every HTTP request. They have a much smaller size limit (~4KB), support expiration dates, and can be configured with security flags. Cookies are primarily for server-side concerns — authentication tokens, session IDs, and tracking.

// Set a cookie with expiration and security flags
document.cookie = [
  'session_id=abc123',
  'expires=Fri, 31 Dec 2025 23:59:59 GMT',
  'path=/',
  'Secure',        // Only sent over HTTPS
  'HttpOnly',      // Not accessible via JavaScript (set by server)
  'SameSite=Strict' // Not sent with cross-site requests
].join('; ');

// Reading cookies (awkward API — returns all as one string)
const allCookies = document.cookie; // "session_id=abc123; theme=dark"

// Parsing a specific cookie
function getCookie(name: string): string | null {
  const match = document.cookie.match(
    new RegExp(`(?:^|; )${name}=([^;]*)`)
  );
  return match ? decodeURIComponent(match[1]) : null;
}

// Delete a cookie (set expiration in the past)
document.cookie = 'session_id=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/';

Storage choice has direct security implications. The wrong choice can expose sensitive data to XSS attacks or leak tokens to third parties.

Use this mental model to pick the right storage mechanism for your use case.

This question tests your understanding of browser storage APIs, their tradeoffs, and security implications. Interviewers want to see that you know when to use each mechanism, understand the security risks of storing sensitive data client-side, and can reason about data lifetime and scope. It's a practical question — every web app needs to store data somewhere, and the wrong choice leads to security vulnerabilities or poor UX.