Introducing the Cross-Origin Storage API

Thomas Steiner

Published: November 10, 2026

Modern web apps often depend on large assets, such as JavaScript frameworks, game engines, and AI models. Despite the fact sites are using identical assets, each site has to download and store their own copy of each.

With the proposed Cross-Origin Storage API, COS for short, the client specifies the content it's looking for by its hash, and fetches it from any URL to share it across the designated sites (or all sites). This means an exact, known resource can be shared across sites, independent from serving the asset. With this proposal comes security benefits and safety challenges.

Use cases

We've written at-length about the importance of caching models and caching any asset with the Cache Storage API. The Cross-Origin Storage API goes a step further, and could be beneficial when multiple related (or otherwise) websites need access to the same resource:

  • AI models: Models like Gemma or Llama variants weigh anywhere from roughly a gigabyte to tens of gigabytes. Storing and retrieving one copy through COS avoids massive duplicate downloads. This is a major motivation behind the proposal.
  • Wasm modules: Frameworks like Flutter ship Wasm files that are requested millions of times a day across thousands of distinct origins, always byte-identical.
  • Popular JavaScript libraries and frameworks: Bundling vendor code separately and in its entirety (such as the complete, untreeshaken React library) lets multiple apps share one cached copy through COS.
  • Game engines: Browser games built on engines like Godot or Unity can share the engine runtime through COS and fetch only game-specific assets over the network. Gaming portals that host many casual games across different origins or iframes benefit the most.
  • Large web fonts: Icon fonts, emoji fonts, and fonts with broad Unicode coverage are downloaded across an enormous number of pages. Sharing them once through COS helps both performance and sustainability.
Two unrelated Three.js games, Descent and Quake, share one copy of the engine through COS, inspected in DevTools.
Two unrelated Three.js games, Descent (in the background tab) and Quake (in the foreground tab), share one copy of the engine through COS, inspected in DevTools. This screenshot is from an experimental Chromium build and may not reflect the final design.

The basic flow of working with COS

The COS API introduces a navigator.crossOriginStorage.getFileHandle() method through which web apps store and retrieve files across origin boundaries, identified by a cryptographic hash. The explainer has an example that shows the basic flow of working with the API.

Try it today

There are two ways to experiment with COS right now:

  • Install a browser extension from the Chrome Web Store, Firefox Add-ons, or Safari App Store to polyfill the API surface and all integrations. You can test the API flow in any browser. Or load the extension unpacked from its source code.
  • Experiment in Chromium: There's an experimental Chromium implementation. Download it for macOS on Apple silicon or Linux x86_64 from goo.gle/cos-chromium, then open about://flags, search for "Cross-Origin Storage", set it to Enabled, and restart when prompted. This build includes a DevTools integration: find Cross-origin storage in the Application tab.

Ecosystem interest

COS is an early-stage proposal, and a number of projects already ship experimental support, typically behind an opt-in flag and layered as a progressive enhancement:

Standardization

Cross-Origin Storage is an early-stage WICG proposal. You can read the early W3C TAG Design Review.

Feedback on the API and the proposal is welcome. You can file issues, show support, or open pull requests in the Cross-Origin Storage repository.

Resources

Plus, check out this tooling and demos:

Additional background reading

Talks and podcasts