Storage Partitioning
Date: 2026-08-17
Storage keyed by the top-level site as well as by origin, so the same embedded third party gets a different, isolated store on every site it appears on. It ends cross-site tracking through storage — and breaks a long list of legitimate embedded functionality that assumed one shared store.
Storage partitioning is keying browser storage — cookies, local storage, caches — by the top-level site as well as the origin that wrote it.
The change
BEFORE — keyed by origin only
alex visits shop-a.com → widget.example writes id=X7K2
alex visits shop-b.com → widget.example reads id=X7K2 ← same value
→ the widget knows it's the same person
across two unrelated sites
AFTER — keyed by (top-level site, origin)
alex visits shop-a.com → (shop-a.com, widget.example) → id=X7K2
alex visits shop-b.com → (shop-b.com, widget.example) → EMPTY
→ writes a new id=P9M4
→ no link between them
One embedded origin, many separate stores. The third party cannot tell that the two visitors are the same person, because nothing it wrote on one site is readable on the other.
What’s partitioned
Effectively everything a page can persist or reuse:
cookies (third-party) localStorage / sessionStorage
IndexedDB Cache API
service worker registrations
HTTP cache ← yes, this too
connection pools blob URLs
The HTTP cache being partitioned is the under-appreciated one. A shared CDN copy of a common library used to be a genuine performance benefit — visit one site, the file is cached, every other site using the same URL got it free. That’s gone, because it was also a tracking vector: a third party could infer which sites you’d visited from what was already cached.
The practical consequence: there is no longer any performance argument for loading a common library from a public CDN. Self-host it. You get the same cold-cache cost, plus one fewer origin to connect to and one fewer third party to trust — Third-Party Scripts, Subresource Integrity.
What it breaks
All legitimate, all now requiring different approaches:
- Single sign-on via an embedded iframe. The auth provider’s iframe on your site has no access to the session cookie it set on its own domain. Redirect-based flows work; silent iframe token refresh generally doesn’t — Authentication Architecture, OAuth and OpenID Connect
- Embedded checkout and payment iframes that relied on remembering a customer across merchants
- Chat, support and personalisation widgets that recognised a returning user across a group’s brands
- Multi-brand groups on separate domains. Two sites you own, one customer, no shared state — this catches organisations by surprise because it feels like it should be allowed. It isn’t; from the browser’s view they’re unrelated sites — Cross-Device Tracking
- Cross-site analytics. The same measurement break as third-party cookie loss, arriving through a different mechanism — Browser Privacy Restrictions
The sanctioned ways through
FIRST-PARTY EVERYTHING serve the third party from a subdomain of
your own site, so it's first-party
← the practical answer for analytics and
chat. see the caveat below
REDIRECT-BASED AUTH a full navigation to the provider and back,
rather than an iframe. works, costs a
page load
POST-MESSAGE + SERVER the iframe asks its own server, the parent
passes state explicitly across the boundary
— Iframes and Sandboxing
STORAGE ACCESS API an embedded frame requests access to its
unpartitioned storage, gated on a user
gesture and often on prior first-party
interaction — Permissions and User Gestures
The last two are the structured ones: explicit cross-boundary messaging — Iframes and Sandboxing — and a permission request gated on a real interaction — Permissions and User Gestures.
The first-party subdomain approach has a caveat worth stating: it makes the storage first-party, but browsers also cap the lifetime of cookies set by scripts, and some tracking-prevention mechanisms look at whether the subdomain resolves to a third-party service. It’s a mitigation, not an exemption — and doing it purely to evade partitioning is the kind of thing regulators and browser vendors both take an interest in — Server-Side Tag Management.
The state of play
Partitioning has been rolled out progressively and unevenly across browsers, on different timelines, with different scopes and different opt-outs. Safari and Firefox moved earliest and furthest; Chromium’s position on third-party cookies specifically has changed direction more than once.
[CHECK: the current partitioning behaviour and third-party cookie status per browser — this has moved repeatedly and any specific claim about what is enabled today needs verifying against the vendors’ own documentation rather than a summary.]
What’s durable regardless of the timeline: design as though cross-site storage doesn’t exist. Every trajectory here points the same way, and a system that doesn’t depend on shared third-party state needs no migration when the next change lands.
Practical
- Audit what depends on third-party storage before it breaks. Auth, chat, personalisation, payments, analytics — test each in a browser with partitioning fully enabled
- Test in Safari deliberately, since it’s furthest along and shows you the destination
- Self-host libraries. No downside remains
- Don’t rely on the HTTP cache being shared between your own sites on different domains
- Move identity server-side where it matters — a first-party session your own server controls is unaffected by any of this — Identity Stitching, Sessions and Tokens
Where it interacts
- Browser Privacy Restrictions — the broader programme this is one mechanism of
- Cookies — the attributes and lifetimes that interact with partitioning
- Iframes and Sandboxing — where the boundary is enforced, and how to communicate across it deliberately
- Fingerprinting — what tracking shifts towards when storage is closed off, and why browsers are reducing that surface too