Storage Partitioning

To strengthen user privacy and combat side-channel cross-site tracking, Chrome now isolates most storage and communication APIs in third-party contexts through a process called storage partitioning.

Implementation status

The feature has been enabled for all users on Chrome 115 and later. Similar storage partitioning efforts are also in place or planned in other major browsers like Firefox and Safari. The Storage Partitioning proposal on GitHub is open for further discussion.

What is storage partitioning?

To prevent certain types of side-channel cross-site tracking, Chrome partitions storage and communications APIs in third-party contexts.

Without storage partitioning, a site can join data across different sites to track the user across the web. Also, it allows the embedded site to infer specific states about the user in the top-level site using side-channel techniques such as Timing Attacks, XS-Leaks, and COSI.

Historically, storage has been keyed only by origin. This means that if an iframe from example.com is embedded on a.com and b.com, it could learn about your browsing habits for those two sites by storing and successfully retrieving an ID from storage. With third-party storage partitioning enabled, storage for example.com exists in two different partitions, one for a.com and the other for b.com.

In general, partitioning means that data written by storage APIs such as Local Storage and IndexedDB within an iframe can no longer be accessed by all contexts sharing the same origin. Instead, that data is now isolated and only available to contexts that share both the same origin and the same top-level site.

Before

Storage APIs without partitioning.
Before storage partitioning, example.com can write data when embedded on a.com, and then read it when embedded on b.com.

After

Storage APIs with partitioning.
After storage partitioning, example.com, when embedded in b.com, cannot access example.com's storage when embedded in a.com.

Storage partitioning on chained iframes

The complexity of storage partitioning significantly increases when iframes are nested, particularly when the same origin appears multiple times within the chain.

For example, A1 contains an iframe for B which contains an iframe for A2 and both A1 and A2 are on the same site. If partitioning only considered the top-level site and the current frame's origin, iframe A2 might mistakenly be treated as 'first-party' because it shares a site with the top-level (A1), despite the cross-site iframe B in between. This could open A2 to security risks like clickjacking if A2 had access to unpartitioned storage by default.

To address this, Chrome adds an "ancestor bit" to the storage partition key. This bit gets set if any document between the current iframe and the top-level site is from a different (cross-site) origin. In this case, Site B is cross-site so the bit would be set for A2 and its storage would be partitioned from A1.

When the iframe chain consists solely of same-site contexts (for example, Site A1 containing A2, which then contains A3), the ancestor bit won't further partition their storage. In such cases, their storage remains shared, keyed by their common origin and top-level site.

For sites that need unpartitioned access across chained iframes, Chrome is experimenting with extending the Storage Access API to enable this use case. As the Storage Access API requires the framed site to explicitly invoke the API, this mitigates the clickjacking risk.

API changes due to partitioning

APIs affected by partitioning can be divided into the following groups:

Storage APIs

  • Quota system
    The quota system is used to determine how much disk space is allocated for storage. The quota system manages each partition as a separate bucket to determine how much space is permitted, and when it is cleared.
    The navigator.storage.estimate() method now provides information specific to the storage partition. Chrome-only APIs such as window.webkitStorageInfo and navigator.webkitTemporaryStorage have been deprecated.
    IndexedDB and Cache storage use the partitioned quota system.
  • Web Storage API
    The Web Storage API provides mechanisms by which browsers can store key-value pairs. There are two mechanisms: Local Storage and Session Storage. They are not quota-managed, but are still partitioned.
  • Origin Private File System
    The File System Access API allows a site to read or save changes directly to files and folders on the device after the user grants access. The Origin Private File System enables an origin to store private content directly to disk. This content remains user-accessible but is now partitioned.
  • Storage Bucket API
    The Storage Bucket API is being developed for Storage Standard which consolidates various storage APIs such as IndexedDB and localStorage by using a new concept called buckets. The data stored in the buckets and the metadata associated with the buckets are partitioned.
  • Clear-Site-Data header
    Including the Clear-Site-Data header in the response allows a server to request to clear the data stored in the user's browser. Cache, cookies, and DOM storage can be cleared. Using the header only clears the storage within one partition.
  • Blob URL store
    A Blob URL provides access to a blob, an object holding raw data. Without storage partitioning, a blob URL generated in a third-party iframe on one site can be used in a same-origin iframe embedded in another site. For example, if example.com iframes are embedded on both a.com and b.com, a blob URL generated in the iframe embedded on a.com can be passed to and then used by the iframe embedded on b.com without any restrictions. Starting with Chrome 137 (released May 27, 2025), Blob URLs are partitioned for all uses except top-level navigations. Cases that will now be blocked include when cross-partition blob URLs are used with fetch() or as the src attribute value for various HTML elements. Top-level navigations, such as calling window.open() or clicking a link with target='_blank', to Blob URLs won't be blocked if they are cross-partition, but noopener will be enforced if the blob URL site is cross-site from the top-level site of the page initiating the navigation. Having noopener enforced means that the document initiating the navigation will be prevented from getting a window handle for the blob URL document it opened. In the earlier example, partitioning will prevent the iframe on b.com from fetching the contents of the blob URL but it will still be able to window.open() it.

Communication APIs

Along with storage APIs, communication APIs that allow one context to communicate across origin boundaries are also partitioned. The changes mainly affect APIs that allow the discovery of other contexts using broadcasting or same-origin rendezvous.

Due to partitioning, the following communication APIs prevent third-party iframes from exchanging data with their same-origin contexts:

  • Broadcast Channel
    The Broadcast Channel API allows communication between browsing contexts (windows, tabs, or iframes) and workers of the same origin.
    The behavior of cross-site iframe postMessage() is not proposed to be changed, as the relationship between those contexts is already clearly defined.
  • SharedWorker
    The SharedWorker API provides a worker that can be accessed across browsing contexts of the same origin.
  • Web Locks
    The Web Locks API allows code running in one tab or worker of the same origin to acquire a lock for a shared resource while some work is performed.

Service Worker API

The Service Worker API allows sites to perform tasks in the background. Sites register service workers that create new worker contexts to respond to events. Traditionally, these workers could communicate with any same-origin context. However, because service workers can alter the timing of navigation requests, they pose a risk of cross-site information leaks like history sniffing.

For this reason, Service Workers registered from a third-party context are now partitioned.

Extension APIs

Extensions are programs that allow users to customize their browsing experience.

Extension pages (pages with a chrome-extension:// scheme) can be embedded on sites across the web. In this scenario, the extension pages continue to have access to their top-level partition. Extensions can also embed other sites; when they do, those embedded sites will access their top-level partition, provided the extension has host permissions for them.

For more information, see the extension docs.

Demo: testing storage partitioning

Demo site: https://storage-partitioning-demo-site-a.glitch.me/

Demo site showing green ticks on the left and red crosses on the right.
Screenshot of the demo, showing the output for a browser with storage partitioning on the left, and without storage partitioning on the right.

The demo uses two sites: site A and site B.

  • When you visit site A in the top-level context it sets data using various storage methods.
  • Site B embeds a page from site A and that embed attempts to read the storage options set previously.
  • When site A is embedded on site B, it doesn't have access to that data when the storage is partitioned and so the reads fail.
  • The demo uses the success or failure of each read to show whether data is partitioned.

For now, you can turn off storage partitioning in Chrome by using the --disable-features=ThirdPartyStoragePartitioning command-line switch. Note: This command-line switch is intended for development and testing purposes and may be removed or changed in future Chrome versions.

You can also test other browsers in the same way to see their partitioning status.

Engage and share feedback