Chrome's October 2026 Privacy Sandbox Removal Explained: What Ad Code Must Do

Ad code that still calls these APIs gets no useful data back, and how it fails depends on the user. Where Chrome still has the stubs, most calls fail quietly. Where the names are already deleted, the calls throw errors. The approved plans take that to all Stable users from late October 2026.

This is the privacy sandbox removal, and its main rollout steps land between 15 October and 3 November 2026. Code written as if the calls always succeed can stop at the first error or leave the ad slot empty.

Picture a common setup. A Hindi news site in Lucknow earns money from display ads, and its ad script runs four steps on every article page. The setup is made up, but each API call in it is real.

• Ask Chrome for the reader's topics, such as "Sports" or "Travel", and send them to the ad server.
• Add readers of cricket stories to an interest group, a named audience list stored in the browser, so a cricket-gear shop can reach them later.
• Run an ad auction inside the browser that picks the best ad for this reader.
• Show the winning ad inside a fenced frame, a frame the page cannot read into.

While the stubs are in place, step 1 answers with an error, steps 2 and 3 quietly do nothing, and step 4 has nothing to show. Once the names are deleted, steps 1 to 3 throw TypeError, the error JavaScript raises when you call something that is not a function. Either way, if the script did not catch the error on step 1, steps 2 to 4 never run. The fix has two parts: check that the name exists, then check that the call really returned data.

You need seven terms. Each one is explained in plain words here, then used through the rest of the guide.

• Privacy Sandbox: a set of Chrome APIs, many of them meant to support ads without third-party cookies. Third-party cookies are cookies set by a site other than the one you are visiting.
• Topics API: the document.browsingTopics() method. It returned a few broad interest labels that Chrome had worked out from your recent browsing.
• Protected Audience: the joinAdInterestGroup() and runAdAuction() methods on navigator. They let a browser store audience lists and run an ad auction on the device. Chrome's own code and DevTools still call it Fledge.
• Fenced frame: an element that works like an iframe but blocks data flow between the ad and the page around it. It existed to display auction winners.
• Stub: a stand-in that keeps a method's name but does no real work. Calling it returns an error or an empty answer instead of crashing.
• Field trial: a server-side switch that turns a code path on for a chosen share of Chrome users.
• Milestone: a numbered Chrome release such as 156. Each one reaches Canary and Beta, early test versions, before the Stable channel, the version most people use. From Chrome 152 to 157, a new milestone reached Stable every two weeks.

The privacy sandbox removal is Chrome deleting the ad-related Privacy Sandbox APIs in stages, with the main rollout steps between 15 October and 3 November 2026. First the settings were to be removed (planned for Chrome 150), then the real code was swapped for stubs. Now the stub names are being deleted for growing shares of users.

Google announced the retirement on 17 October 2025. Each API then got its own blink-dev thread, the public mailing list where Chrome engineers ask approval to ship or remove web features.

The Protected Audience and Topics threads both used the same four-step plan, posted on 11 June 2026. Step one, planned for Chrome 150, was to remove the ad settings through a field trial, after which calls in browsers in that trial would "always reject". Step two replaced the real code with a lightweight stub.

Steps three and four remove the stub through a field trial: first on Canary and Beta, then 1% of Stable. Full removal needs a fresh approval once 1% shows no breakage. The table shows where each API is.

Chrome is removing them because few sites used them once Chrome decided to keep third-party cookies. Google's 17 October 2025 post cites ecosystem feedback and "low levels of adoption" as the reasons.

The Topics and Protected Audience Chrome Status entries make the link to cookies plain. They say the APIs are going because Chrome will keep its current approach to third-party cookies. The APIs were built as a replacement for those cookies, so the case for them weakened.

Usage also fell over the year. The Topics thread reported calls on about 13% of page loads in November 2025, 4.9% in June 2026 and 2% in September 2026. The fenced frame thread reported the element on about 0.07% of page loads.

Those numbers count page loads where Chrome's use counters saw the API used. They do not count ads actually shown. Low use does not mean no breakage, as the next section shows.

A stub keeps the method's name but does no real work. So the classic check 'does this name exist?' passes, while the call itself fails or returns nothing. The fenced frame thread states this directly.

In that thread, the engineer who posted the removal intent explained why feature detection is not a reliable signal. The interface stays defined even when Privacy Sandbox is turned off, and the auction calls return null or reject.

Think of a closed railway ticket counter that still has its sign and window. You can queue and ask, and you either get a polite refusal or simply no ticket. The sign tells you nothing about whether tickets are sold.

Mapped to code, the sign is the method name, asking is the call, the refusal is a rejected promise and "no ticket" is a null result. Where the picture breaks: a closed counter turns everyone away the same way. The Topics stub rejects with a clear error, while the auction stub quietly returns null.

What we saw when we ran the APIs in Chromium 153

We launched Chrome for Testing 153.0.8010.12 through Playwright 1.63.0 on a localhost page on 24 October 2026. Playwright starts Chrome with field-trial config turned off, so this shows the build's own defaults, not what a Stable user with field trials sees.

Chromium 156 or newer was not available in our test setup. The behaviour of 156 and 157 below comes from Chrome's own release notes and Chrome Status, not from our run.

Two more details showed up. Calling the APIs raised deprecation issues in DevTools, of types "Topics" and "Fledge". A Permissions-Policy header naming join-ad-interest-group or run-ad-auction now logs an "Unrecognized feature" warning in the console.

Secure context matters too. The Topics and Protected Audience methods only exist on secure pages, meaning HTTPS or localhost. On a plain data: URL those names were absent, and calling document.browsingTopics() threw TypeError: "document.browsingTopics is not a function". The fenced frame interface was still defined there.

Some users still have the API names because the last step is a field trial, which reaches users in shares and can be paused or rolled back. A Stable user may be inside or outside the trial group, or may run an older Chrome.

One approval in the Topics thread was conditional on a progressive field-trial rollout, so breakage could be watched and the change rolled back. That matches the shape of both plans: 1%, then 10% for about two weeks, then 100%.

For a page, there are three kinds of Chrome visitor. The diagram walks through what document.browsingTopics() does for each one.

Is the removal milestone 152 or 153?

Nobody from Chrome has settled it in public as of 24 October 2026, so treat any Chrome from 152 on as stubbed or name-free. Chrome's own pages disagree; here is who says what.

• The 11 June 2026 plan in both threads put the stub in Chrome 152.
• On 23 September, the Protected Audience thread reported no regressions on 1% of Stable, written as "M152+".
• On 24 September, the Topics thread reported 1% of Stable, written as "M153+".
• Both Chrome Status entries, last updated on 21 August 2026, list 153 as the removal milestone.
• On 7 September a reader in the Protected Audience thread noticed the methods still existed in Chrome 152 Stable. They asked whether the date slipped, and the thread has no reply.

The methods still existing is not proof of a slip, because a stub keeps the names by design. Our 153 run shows the same names present with the work gone. For your code the answer is the same either way.

Chrome 156, Stable since 20 October 2026, turns the fenced frame element and the window.fence methods into stubs. No JavaScript call on them throws, and the window.fence reporting methods do nothing.

Chrome Status gives the reason this is safe. With Protected Audience and selectURL() removed, fenced frames can no longer be navigated, so they have nothing to show.

For Chrome 157, a field trial on Canary and Beta is planned to remove the stub element. Full removal on Stable needs another approval after 1% of Stable shows no breakage.

The layout trap when the element becomes unknown

Once the element is removed, the browser treats a fencedframe tag as an HTMLUnknownElement, its type for any tag it does not know. The fenced frame thread warns that it then loses its default 300 by 150 pixel size and collapses unless styled.

Our run shows the gap. In Chromium 153 a fenced frame measured 304 by 154 pixels. An unknown fakeframe tag measured 0 by 0, and a plain div holding only that tag collapsed to 0 height.

A div sized to 300 by 250 pixels in CSS kept that size with either tag inside. So size the slot's container, not the fenced frame. Better still, stop creating fenced frames at all, because there is no auction winner left to put in them.

Check that the name exists, then call it inside try and catch, and treat a rejection or a null result as "not available". The name check alone fails during the stub period, and the call alone throws once the name is deleted.

The helper below wraps the calls behind steps 1 to 3 of the news site's ad script. It runs both checks and falls back to contextual ads, meaning ads picked from the page's own content. You can paste it into the DevTools console on an HTTPS page to try it.

async function getTopicsSafely() {
  if (!('browsingTopics' in document)) {
    return { status: 'absent', topics: [] };
  }
  try {
    const topics = await document.browsingTopics();
    return { status: 'available', topics };
  } catch (err) {
    return { status: 'removed-or-blocked', topics: [], reason: err.name };
  }
}

async function joinGroupSafely(group, seconds) {
  if (typeof navigator.joinAdInterestGroup !== 'function') {
    return 'absent';
  }
  try {
    await navigator.joinAdInterestGroup(group, seconds);
    return 'called';
  } catch (err) {
    return 'failed';
  }
}

async function runAuctionOrNull(config) {
  if (typeof navigator.runAdAuction !== 'function') {
    return null;
  }
  try {
    return await navigator.runAdAuction(config);
  } catch (err) {
    return null;
  }
}

async function chooseAd() {
  const topics = await getTopicsSafely();
  const winner = await runAuctionOrNull({
    seller: location.origin,
    decisionLogicURL: location.origin + '/decide.js',
    interestGroupBuyers: [location.origin],
  });
  if (winner === null) {
    return { source: 'contextual', topicsStatus: topics.status };
  }
  return { source: 'auction', topicsStatus: topics.status };
}

To check it worked, run await chooseAd() in the DevTools console. In our Chromium 153 run on localhost it returned source "contextual" and topicsStatus "removed-or-blocked". joinGroupSafely() returned "called", because the stub resolves even though it stores nothing you can inspect.

We also simulated deleted names by removing the three methods from their prototypes before loading the helper. Then chooseAd() reported topicsStatus "absent" and joinGroupSafely() returned "absent", with no uncaught error.

Once the stub names are really deleted for your users, expect the same "absent" result on HTTPS pages. A result of "available" on Chrome 153 or newer would be a surprise worth logging and reporting.

Find every call, wrap or delete it, give ad slots a fixed size and remove dead headers. Treat 3 November, when Chrome 157 reaches Stable, as a practical target, not the day Stable removal is complete.

1. 1

   Search your code and tags

   Look for browsingTopics, Sec-Browsing-Topics, joinAdInterestGroup, runAdAuction, fencedframe, window.fence, sharedStorage and selectURL. Include tag manager containers and inline scripts.

2. 2

   Wrap what you cannot delete yet

   Use the helper pattern: a name check plus try and catch. Treat null from runAdAuction() as no ad, never as an error to retry.

3. 3

   Delete what you own

   The real code is gone from Chrome 152 or 153 onward, so these calls cannot return useful data there. Removing them also removes the DevTools deprecation issues.

4. 4

   Fix the ad slot layout

   Give each ad container an explicit width and height, and render fallback ads in a normal iframe instead of a fenced frame.

5. 5

   Clean up headers and attributes

   Drop join-ad-interest-group and run-ad-auction from Permissions-Policy headers to stop console warnings. Handle the two Topics names in the next step.

6. 6

   Decide on the opt-out headers

   The Topics plan also removes browsing-topics and interest-cohort, which 153 still recognised. Keep or drop them together: keeping browsing-topics=() still opts your site out on old Chrome versions with the real code. If Chrome stops recognising it, expect a console warning like the one join-ad-interest-group gave in our run. The browsingtopics attribute on iframe and img is ignored per the Topics plan.

7. 7

   Ask your ad vendors

   If the calls come from a third-party ad script, ask which version stops calling these APIs and when it ships.

8. 8

   Test on Chrome 156 and 157

   Load your pages in Chrome 156 Stable and Chrome 157 Beta and open the DevTools Issues panel. Your browser may be outside the trial, so check document.createElement('fencedframe').constructor.name first. HTMLFencedFrameElement means the stub is still there; HTMLUnknownElement means the element is removed.

9. 9

   Simulate the removed element

   In the Elements panel, rename a fencedframe tag to an unknown name such as fakeframe. Confirm the ad slot keeps its size, whatever trial group your browser is in.

CHIPS, FedCM and Private State Tokens stay, according to Google's 17 October 2025 post. CHIPS gives each top-level site its own copy of a third-party cookie. FedCM supports "sign in with" buttons, and Private State Tokens help fight fraud.

The same post also retires Attribution Reporting, Private Aggregation and Related Website Sets, plus the Android versions of several APIs. Those have their own removal threads and dates, which this guide does not cover.

In our Chromium 153 run, Attribution Reporting's attributionSrc and Related Website Sets' requestStorageAccessFor() were still present. Do not assume they share the Topics dates; check their own Chrome Status entries.

Treat it as a question about building on a platform API that can disappear. Interviewers listen for how you handle a dependency you do not control.

1. 1

   State the change in one line

   Chrome is removing Topics, Protected Audience and fenced frames in stages: code replaced by stubs, then names deleted through a field trial.

2. 2

   Name the failure modes

   A call can reject, return null or not exist at all. An element can lose its default size. Each needs a separate check.

3. 3

   Design for absence

   Wrap every optional browser API behind one module that returns a clear status. The rest of the ad code reads that status and falls back to contextual ads.

4. 4

   Explain the rollout model

   Field trials reach 1%, then 10%, then 100% of users, and can be rolled back. Your code sees mixed behaviour during that window.

5. 5

   Add observability

   Log the status each user gets, such as available, removed-or-blocked or absent, by Chrome version. That shows when it is safe to delete the fallback.

6. 6

   Close with the trade-off

   Detection code costs little and protects revenue during the rollout. Deleting the calls entirely is cleaner once logs show no user gets real data.