Web Storage Origin Scoping

Web Storage is scoped to an origin, identified by scheme, host, and port. Pages with different origins generally cannot access each other's `localStorage` or `sessionStorage` objects.

An origin is the combination of a URL's scheme, host, and port. For example, `https://example.com` and `http://example.com` have different origins, and `https://example.com:443` and `https://example.com:8443` are also different origins.

`localStorage` provides a persistent storage area associated with an origin. A script running in one origin can normally read and modify only that origin's `localStorage`; another origin gets a separate storage area. This prevents unrelated websites from directly sharing Web Storage data.

`sessionStorage` is also origin-scoped, but it has an additional browsing-context dimension. Its data is associated with the origin and the particular top-level browsing context, so separate tabs or windows generally have separate `sessionStorage` areas even when they display the same origin.

Origin scoping is distinct from URL path scoping. For example, `https://example.com/a` and `https://example.com/b` have the same origin because their scheme, host, and port match, so scripts from those pages can normally access the same `localStorage` area. Storage access can still be affected by browser privacy policies, sandboxing, or other security restrictions.

Key points

Interview questions

What determines whether two pages share the same Web Storage?

The key concept is the origin, which consists of scheme, host, and port. If those three components match, pages normally have the same origin and can access the same `localStorage` area. A different scheme, host, or port creates a different origin. The URL path does not affect the origin.

Would `https://example.com/app` and `https://example.com/shop` share `localStorage`?

Yes, assuming no other browser security or privacy mechanism changes the behavior. Both URLs use the same scheme, host, and port, so they have the same origin. Their different paths do not create separate Web Storage areas. Consequently, scripts from those pages normally access the same `localStorage` namespace.

Why can't JavaScript on one origin simply read another origin's localStorage?

Web Storage follows the browser's same-origin security model. Each origin has its own storage namespace, so JavaScript normally receives access only to the storage associated with its own origin. This prevents an unrelated site from directly reading stored data belonging to another site. Cross-origin communication, when intentionally designed, uses mechanisms such as `postMessage` rather than direct Web Storage access.

How is sessionStorage scoping different from localStorage scoping?

Both are associated with an origin, but `sessionStorage` also has a browsing-context dimension. Two separate tabs showing the same origin normally have separate `sessionStorage` objects. `localStorage`, by contrast, is shared by documents of the same origin and is intended to persist beyond the lifetime of an individual page session. Browser privacy features can impose additional restrictions.

What is the difference between same-origin and same-site, and why does it matter?

Same-origin is a strict identity check using scheme, host, and port. Same-site is a broader security concept based on the site's registrable domain and scheme, so two URLs can be same-site while still being cross-origin. This distinction matters because different browser mechanisms use different boundaries. Web Storage uses origin-based scoping, while cookies and other browser security features can apply site-related rules.