Browser Storage & Web APIs

localStorage and sessionStorage

localStorage and sessionStorage are simple key-value stores built into every browser. Both use the same API: setItem(key, value), getItem(key), removeItem(key), and clear(). The difference is lifespan: localStorage persists indefinitely, until the user or your code clears it, even after closing the browser entirely, while sessionStorage is wiped as soon as the tab is closed. Both only store strings, so to save an object or array you must convert it with JSON.stringify() before saving, and convert it back with JSON.parse() when you read it out.

1const preferences = { theme: "dark", fontSize: 16 };23localStorage.setItem("preferences", JSON.stringify(preferences));45const saved = JSON.parse(localStorage.getItem("preferences"));6console.log(saved.theme); // "dark"

A safe pattern is to always guard your reads: localStorage.getItem returns null if the key doesn't exist yet, and calling JSON.parse(null) actually returns null rather than throwing, but it's clearer to check explicitly and provide a sensible default. This matters the first time a user visits your page and there's nothing saved yet. It's also worth remembering that storage is per-origin, meaning localStorage on example.com is completely separate from localStorage on another-site.com, and that anything you store there is readable by anyone with access to that browser, so it should never hold sensitive information like passwords.

1function loadJSON(key, fallback) {2  const raw = localStorage.getItem(key);3  if (!raw) return fallback;4  try {5    return JSON.parse(raw);6  } catch {7    return fallback;8  }9}1011const cart = loadJSON("cart", []);

Persisting UI state across reloads

A very common use of storage is remembering a user's preference, like light or dark mode, or the last tab they had open. The pattern is always the same: read from storage when the page loads and apply that state immediately, then write to storage whenever the state changes, usually inside the same event handler that updates the DOM. This combines skills from earlier chapters directly: the event listeners you already know for reacting to clicks, and the DOM manipulation you already know for applying classes, now paired with storage so the change survives a reload instead of resetting every time.

Other Web APIs worth knowing

localStorage is just one of many APIs the browser exposes on the global window and navigator objects, all designed to feel like ordinary JavaScript. The Geolocation API (navigator.geolocation.getCurrentPosition) asks the user for permission and returns their coordinates. The Clipboard API (navigator.clipboard.writeText) lets you copy text programmatically, commonly used for 'copy link' buttons. The Notifications API can show system notifications with permission. Most of these follow a similar shape: they're asynchronous (often Promise-based), and they typically require the user to grant permission first, which the browser handles with a built-in prompt.

• localStorage persists until explicitly cleared, across browser restarts
• sessionStorage clears when the tab closes
• Both APIs only store strings, so use JSON.stringify/JSON.parse for objects
• Never store sensitive data like passwords in browser storage
• Storage is separate per origin (domain)
• Many Web APIs (geolocation, clipboard) require user permission and are Promise-based

It's tempting to reach for storage for everything, but it has real limits worth knowing: it's synchronous (which can block the main thread if you store large amounts of data), it's capped at roughly five megabytes per origin in most browsers, and it isn't designed for structured queries. For genuinely large or complex client-side data, browsers offer IndexedDB, a more powerful asynchronous database, but for preferences, small caches, and simple persistence, localStorage is usually the right, simple tool for the job.