Storage in the Browser: Cookies, localStorage, sessionStorage and IndexedDB

"Where should I store this?" is a daily decision. It is also a favourite interview question. A wrong answer can leak a login token, lose a user's cart, or send 4 KB of extra data on every request. This lesson explains each store and gives you a table you can remember.

The five stores at a glance

A few words in this table need a short explanation:

• Origin means the scheme, host and port together. For example, https://app.example.com:443. Scheme is the start of the URL (https), host is the name (app.example.com), port is the number after the colon (443).
• Synchronous means the code stops and waits until the job is done. Asynchronous means the code keeps running and gets the result later.
• A Web Worker is a JavaScript file that runs in a separate background thread next to your page, so heavy work does not freeze the page. (A thread is one line of work that a program runs.)
• Expires / Max-Age are cookie settings that say when the cookie dies. They are explained below.
• HttpOnly is a cookie setting that hides the cookie from JavaScript. It is explained below.
• The Cache API is a browser store for saved network responses. It is explained below.
• A blob is a chunk of raw binary data, such as an image or a file.

Learn the first three rows well: lifetime, scope, and automatically sent. Most interview answers are built from them.

Cookies

A cookie is a small piece of text (a name and a value) that the browser stores for a site. The server asks the browser to remember it with a Set-Cookie response header. (A header is a named line of extra information that travels with a request or a response.) After that, the browser sends it back on later requests to the same site, in a Cookie request header. It is like a wristband at a festival: you show it every time you walk through a gate.

HTTP/1.1 200 OKSet-Cookie: session_id=abc123; Max-Age=3600; Path=/; Secure; HttpOnly; SameSite=Lax

Every later request to that site carries it:

GET /api/me HTTP/2Cookie: session_id=abc123

What each attribute does

Cookie name prefixes

A prefix is a fixed word at the start of a cookie name. It makes the browser enforce (force) rules:

• __Secure- requires the Secure attribute.
• __Host- requires Secure, Path=/, and no Domain. This ties the cookie to the exact host. A sibling subdomain cannot overwrite it. Use __Host- for session cookies when you can.

Why cookies are special

Cookies are the only store that the server receives automatically. This makes them a good home for a session ID (a random value that stands for one logged-in visit). It is also the reason CSRF exists: the browser adds the cookie even when another site started the request.

Cookies also cost bandwidth (the amount of data you send over the network). Say a domain serves 60 files and your cookie is 3 KB. Then about 180 KB of cookie data is uploaded for one page load. So keep cookies small. Where it matters, serve static files from a domain or path that has no cookies.

Reading and writing from JavaScript

// Writing (cannot set HttpOnly this way, only the server can)document.cookie = "theme=dark; Max-Age=31536000; Path=/; SameSite=Lax; Secure";// Reading gives ONE string of every non-HttpOnly cookieconsole.log(document.cookie); // "theme=dark; locale=en-IN"

The document.cookie API is awkward. You get one long string and must split it yourself. So people use small libraries, or the newer Cookie Store API (an async, easier way to read and write cookies) in browsers that support it.

localStorage

localStorage is a browser store that keeps data as key-value pairs (like a dictionary: you save a value under a name and read it back by that name). It keeps strings (text). It is limited to the origin (scheme + host + port). The data stays until someone clears it.

localStorage.setItem("theme", "dark");localStorage.getItem("theme");          // "dark"localStorage.setItem("prefs", JSON.stringify({ density: "compact" }));JSON.parse(localStorage.getItem("prefs") ?? "{}");localStorage.removeItem("theme");

Things you should know:

• It is synchronous. A big read or write blocks the main thread (the one thread that runs your JavaScript and also draws the page), so the page can freeze. Do not store megabytes of JSON that you parse again on every render.
• It stores strings only. Everything goes through JSON.stringify (turns an object into text) and JSON.parse (turns that text back into an object).
• All tabs of the origin share it. When one tab changes a value, the other tabs of the same origin get a storage event (the browser tells them something changed; the tab that made the change does not get it). You can use this to sync a logout or a theme across tabs:

window.addEventListener("storage", (e) => {  if (e.key === "theme") applyTheme(e.newValue);});

• All scripts on the origin share it. This includes your analytics snippet, your chat widget and any hacked dependency. There is no permission per script. This is the reason for the token-storage warning in Lesson 03. (A token is a piece of data that proves who you are.)
• It is not sent to the server. So it costs no bandwidth. But the server cannot use it when it builds the page. It does not exist on the server. In Next.js, a component that reads it must run on the client (in the browser) after the page loads.
• It is not guaranteed to stay. Users clear site data. Browsers delete data when space runs low. Safari's tracking prevention can delete script-written storage if the user has not used the site for about seven days.

sessionStorage

sessionStorage has the same API as localStorage. The difference is the scope: it belongs to one tab (a browsing context), and it is cleared when the tab closes.

• It survives a page reload and moving to other pages inside the same tab.
• Each tab has its own copy. If you open the same site in a second tab by typing the URL, that tab starts empty. (If code opens a new tab with window.open and does not use noopener, the new tab may get a one-time copy of the old tab's values, and then the two tabs go their own ways. Links with target="_blank" use noopener by default in modern browsers, so they do not copy. Do not rely on any of this to share data.)
• It does not fire storage events across tabs, because tabs do not share it.

Good uses: a draft of a multi-step form, the progress of a wizard, a one-time redirect target, or "did I already show this banner during this visit?".

IndexedDB and the Cache API

IndexedDB is a database built into the browser. It is asynchronous, and it supports transactions (a group of changes that all succeed or all fail together). It can store structured data such as objects, arrays, Blobs and Files. It has indexes (extra lookup lists), so you can search by a range of keys. It also works in Web Workers and Service Workers (a Service Worker is a background script that sits between your page and the network and can answer requests itself).

Difference in one line: localStorage is a small, simple, blocking store for text. IndexedDB is a large, non-blocking database for structured data.

Use IndexedDB when you have a lot of data or data that is not a string. For example: records for an offline-first app, cached API lists, or drafts with attachments.

// Minimal raw usage (in practice you would wrap it with a small library such as idb)const open = indexedDB.open("app", 1);open.onupgradeneeded = () => open.result.createObjectStore("drafts", { keyPath: "id" });open.onsuccess = () => {  const tx = open.result.transaction("drafts", "readwrite");  tx.objectStore("drafts").put({ id: 1, body: "Hello", updatedAt: Date.now() });};

The Cache API is a browser store that saves whole network requests together with their responses. It is used mostly from Service Workers. It stores Request and Response pairs (a Request is what the page asked for, a Response is what came back). This is exactly what you need for an offline page shell or for cached files.

Quota and eviction: The browser gives each origin a share of disk space. This share is called the quota (the maximum you may use). Eviction means the browser deletes your data to free space. Use navigator.storage.estimate() to see how much you use and how much you may use. Use navigator.storage.persist() to ask the browser not to delete your data when space is low. The browser may say no. Any data you store may disappear. So treat it as a cache of something you can get back, not as the only copy.

Decision table: where does this data belong?

A safe storage wrapper

Storage calls can throw errors. This happens in private modes, when cookies are blocked, when the quota is full, or inside an iframe without access. Never assume storage works. (try/catch is JavaScript syntax that runs the catch block if the try block throws an error.)

type Json = string | number | boolean | null | Json[] | { [k: string]: Json };export const safeStorage = {  get<T extends Json>(key: string, fallback: T): T {    try {      const raw = localStorage.getItem(key);      return raw === null ? fallback : (JSON.parse(raw) as T);    } catch {      return fallback; // storage blocked, or corrupted JSON    }  },  set(key: string, value: Json): boolean {    try {      localStorage.setItem(key, JSON.stringify(value));      return true;    } catch {      return false; // QuotaExceededError, SecurityError, ...    }  },};

In Next.js, remember that Server Components and the first server render have no localStorage. Read it in an effect after the page loads. If you do not, you will get a hydration mismatch (hydration is when the browser attaches your JavaScript to the HTML from the server; a mismatch means the browser's result differs from the server's HTML).

Common mistakes

1. Storing JWTs (JSON Web Tokens, signed tokens that prove identity; see Lesson 02) or session IDs in localStorage. Any XSS bug (XSS, cross-site scripting, means an attacker's JavaScript runs on your page), even one in a third-party script, can read the value and send it to the attacker.
2. Using localStorage for data the server needs on the first render (such as theme or language). The server cannot see it, so the page flashes the wrong theme. Use a cookie for this.
3. Putting big objects in cookies. Cookies are sent on every request, even for images. Keep an ID in the cookie and the data on the server.
4. Setting Domain on a cookie "to be safe". It does the opposite. It shares the cookie with every subdomain.
5. Thinking storage is permanent. Treat browser storage as a cache that can vanish.
6. Believing Path is security. It only limits where the cookie is sent. Any page on the same origin can still read the cookie with script (unless it is HttpOnly) or through an iframe.
7. Forgetting try/catch around storage calls.

Interview questions

Key takeaways

• Choose a store by lifetime, scope, and whether the server needs the data automatically.
• Cookies are the only store sent to the server automatically. Their attributes (HttpOnly, Secure, SameSite, and no Domain) are your security controls.
• localStorage is shared by the whole origin. It is synchronous, strings only, and every script can read it. Never keep secrets there.
• sessionStorage belongs to one tab and ends with the tab.
• Use IndexedDB for big or structured data. Always wrap storage calls in try/catch.

What's next

Lesson 02: Sessions vs JWT. Now you know where a credential can live. Next we look at what the credential is: a plain session ID that the server looks up, or a signed token that the client carries.