If you store data in localStorage on one domain, can another domain access it?
No — localStorage is scoped by **origin** (scheme + host + port). `https://a.com` and `https://b.com` see different storage. But same origin includes subdomains only if you configure document.domain (deprecated) or use postMessage from an embedded iframe of the original origin. Caveat: XSS on the original site reads it freely.
localStorage is partitioned by origin. Origin = scheme + host + port. https://a.com ≠ https://b.com ≠ http://a.com ≠ https://sub.a.com ≠ https://a.com:8080.
Same-origin examples
| URL A | URL B | Same origin? |
|---|---|---|
| https://a.com/x | https://a.com/y | Yes |
| https://a.com | https://www.a.com | No (different host) |
| https://a.com | http://a.com | No (different scheme) |
| https://a.com | https://a.com:8443 | No (different port) |
What about subdomains?
Different by default. Workarounds:
document.domain = "a.com"— deprecated, blocked by Origin-Agent-Cluster headers, do not use for new code.- An iframe on the parent origin that postMessages to the subdomain. The subdomain still can't read directly.
- A shared backend that issues the same JWT to both.
How another site could still read it
- XSS on a.com — any injected JS runs at the origin, sees localStorage.
- Browser extensions with broad permissions.
- Devtools / physical access — local data is local.
That's why never store secrets in localStorage. Specifically:
- Auth tokens (use httpOnly cookies — JS can't read).
- API keys.
- PII unless you've thought through XSS risk.
Related storage scopes
| Storage | Scope |
|---|---|
| localStorage | Origin, persistent |
| sessionStorage | Origin + tab, cleared on tab close |
| Cookies | Domain + path; can scope across subdomains |
| IndexedDB | Origin |
| Cache API / Service Workers | Origin |
Cross-origin sharing
If you genuinely need cross-origin storage:
- Shared cookie scoped to parent domain (
Domain=.example.com). - postMessage between an iframe and the parent.
- Server-side state keyed by user.
But "share localStorage across origins" is not directly possible — it's a deliberate browser isolation.
Interview framing
"localStorage is origin-scoped (scheme + host + port). a.com and b.com can't read each other; a.com and sub.a.com can't either by default. The browser enforces this. But anything that runs JS on the origin — XSS, an extension, devtools — can read it freely. So never store auth tokens or secrets there; use httpOnly cookies. For legitimate cross-origin sharing, use a shared cookie scoped to the parent domain, postMessage between iframes, or server-side state."
Follow-up questions
- •How is sessionStorage different?
- •Why are httpOnly cookies safer for auth tokens?
- •How does Site Isolation / partitioning affect this?
Common mistakes
- •Storing JWTs in localStorage and being surprised by XSS exposure.
- •Assuming subdomains share storage.
- •Treating localStorage as 'secure' because the user can't easily see it.
Performance considerations
- •Synchronous API — large blobs in localStorage block the main thread. For anything > a few KB, use IndexedDB.
Edge cases
- •Browser storage partitioning (Firefox total cookie protection, Safari ITP) changes 3rd-party storage rules.
- •File:// origins behave specially.
- •Service worker scope subtleties.
Real-world examples
- •Auth library docs warning against localStorage tokens, OWASP cheatsheets on storage.