The Shared Storage API — A Privacy-Preserving Way to Do Cross-Site Storage

The gap third-party cookie deprecation actually leaves

Most write-ups about third-party cookie deprecation focus on ad targeting, and stop there. But cookies quietly did other jobs too: capping how many times a user sees a given message across your properties, running consistent A/B test buckets across subdomains, and computing aggregate metrics ("how many unique users saw this campaign across all our sites") without a shared server-side identity system. Once third-party cookies are gone, all of that breaks — and most teams haven't built a replacement because it hasn't broken loudly yet.

The Shared Storage API, part of Chrome's Privacy Sandbox, is a purpose-built replacement for exactly this class of problem. It's not a cookie substitute you swap in line-for-line — it's a different shape entirely, and understanding that shape is the whole trick to using it well.

The core idea: write freely, read only inside a sandbox

Shared Storage is a key-value store scoped to an origin, writable from that origin's own JavaScript context anywhere it's embedded (including third-party iframes). The privacy-preserving trick is on the read side: you cannot read Shared Storage values directly in normal page JavaScript. Reads only happen inside a worklet — a locked-down JavaScript execution context with no network access, no access to the outer page's DOM, and no way to pass raw data back to the calling page.

// Writing — works from regular page or iframe JS
await window.sharedStorage.set("impression-count", "3");
await window.sharedStorage.append("campaign-seen", "summer-sale");

// Reading — only inside a worklet, and only for approved output APIs
await window.sharedStorage.worklet.addModule("worklet.js");
await window.sharedStorage.run("log-impression", { data: { campaignId: "summer-sale" } });

Inside the worklet, you can read every key you wrote, run logic on it, and then do exactly one of two things with the result: render a URL chosen from a fixed, pre-registered list (selectURL), or contribute a value to a noised, aggregated report that surfaces later, in bulk, with statistical noise added (Private Aggregation API). You cannot exfiltrate a single user's raw value back to the page. That constraint is the entire privacy model — worth sitting with, because it changes what problems this API is even shaped to solve.

What it's actually good for

• Frequency capping across your own properties. If you own multiple domains or embed content across sites you control, Shared Storage lets you cap "show this banner at most 3 times" without a server round-trip or a first-party cookie that doesn't survive cross-site embedding.
• Consistent A/B bucketing across embeds. selectURL can pick between up to 8 pre-registered URLs based on worklet logic — enough to bucket a user into a consistent experiment variant across every site that embeds your content, without the page ever learning which bucket was chosen.
• Aggregate, privacy-safe reporting. "How many unique users across our network saw this creative" is exactly the Private Aggregation API's use case: individual contributions are invisible, but the summed, noised total is still statistically useful at real scale.

What it's not good for

Being direct about the limits saves you a wasted afternoon:

• Not a general cross-site identity solution. You cannot read a value and act on it synchronously in the page. If your use case needs "know this is the same user and immediately change what renders," Shared Storage's output constraints won't let you do that outside the fixed-URL-selection case.
• Not useful for small-scale reporting. Private Aggregation's noise is calibrated for real query volume. At low traffic, the noise can dominate the signal — this is built for network-scale reporting, not a 50-user beta.
• Chrome-only, and still evolving. As of today this is a Chromium/Privacy Sandbox feature; Safari and Firefox have not shipped equivalents and have been publicly skeptical of parts of the Privacy Sandbox model. Treat this as a progressive enhancement, not your only mechanism, for the foreseeable future.

Where to actually look at it first

Chrome DevTools has first-class support: open Application panel → Storage → Shared Storage, and you'll see per-origin entries, creation time, and byte usage — useful for confirming writes are actually landing before you build worklet logic on top. It's a good five-minute sanity check before you invest in the harder part, which is worklet design.

Should you build on this now?

If most of your cross-site personalization and reporting already runs through a shared backend and authenticated users, you may not need this at all — server-side identity solves the same problem with fewer constraints when you actually have login. Shared Storage earns its complexity specifically for the logged-out, cross-site-embed case that used to lean on third-party cookies and now has nothing else covering it. If that's your situation, it's worth a prototype now, while third-party cookies still exist as a fallback and the migration isn't urgent yet.

Migrating off third-party cookies?

We've helped clients audit exactly which cookie-dependent flows actually need a Privacy Sandbox replacement versus which ones just need a server-side rethink. Tell us what's breaking and we'll give you an honest read on which path is less work.