Chrome third-party cookies in 2026: what actually happened and what publishers should do now

By Valuad AdOps team - - 5 min read

Illustration of an intact cookie in front of a browser window, with a faded sandbox bucket set aside

If you read an ad tech blog this year that told you Chrome would switch off third-party cookies "in Q2 2026", you can relax. It didn't happen, and it isn't scheduled to. Google changed course in 2024, dropped the user-choice prompt it proposed instead in 2025, and in October 2025 announced it was retiring most of the Privacy Sandbox APIs that were meant to replace cookies.

That leaves publishers in a strange spot. Years of roadmap planning were built around a deadline that no longer exists, and some vendors still sell against it. Here is the sequence as Google published it, what is still live in Chrome, and what we think is worth changing in a header bidding setup today.

The timeline, from Google's own posts

July 22, 2024. Google announced "a new path": instead of deprecating third-party cookies, Chrome would introduce an experience that let people make an informed choice across their browsing.

April 22, 2025. Google said it would not roll out a standalone prompt for third-party cookies either. Users keep the existing controls in Chrome settings. Cookies stay on by default.

October 17, 2025. Google announced it was retiring a long list of Privacy Sandbox technologies on Chrome and Android, citing low adoption and industry feedback. The list includes Topics, Protected Audience, Attribution Reporting, Shared Storage, Private Aggregation, Related Website Sets and IP Protection. Chrome keeps CHIPS (partitioned cookies), FedCM and Private State Tokens.

The same day, the UK Competition and Markets Authority released Google from its 2022 Privacy Sandbox commitments, saying its competition concerns no longer arose.

Removal in Chromium. The Chromium intent to deprecate and remove Topics targets deprecation in Chrome 144 and removal in Chrome 150. Protected Audience has a similar intent.

Prebid followed. Prebid.js 11, released in March 2026, removed the PAAPI modules (paapi, paapiForGpt, topLevelPaapi) outright. If your wrapper still loads a Topics or PAAPI module, it is dead weight at best.

Chrome has about 69% of worldwide browser share according to StatCounter's August 2026 numbers. Third-party cookies work there by default, subject to the user's own settings.

Safari (about 16%) has blocked cross-site cookies by default since March 2020, and Firefox has partitioned them with Total Cookie Protection since 2022. So the "cookieless" traffic that everyone was preparing for is already a fifth or more of a typical audience, and more than that on mobile-heavy sites with a lot of iPhone readers. That part of the problem never went away.

Two things follow from this:

  1. Your Chrome traffic keeps its cookie-based match rates, as long as bidders can actually sync.
  2. Your Safari and Firefox traffic still monetizes worse, and nothing from Google is coming to fix it.

What we would change in a Prebid setup now

Remove the Privacy Sandbox leftovers

Look for Topics (topicsFpdModule), PAAPI and fledge configuration in your wrapper build and page code. On Prebid 11 the PAAPI modules no longer exist. On older versions they add bytes and code paths for APIs Chrome is removing. Topics modules are the easiest to miss, because they were added to a lot of builds in 2023 and 2024 and nobody went back to them.

With cookies staying in Chrome, user sync is still where a lot of bid value comes from. Check three things:

  • Sync is enabled for the bidders that need it. userSync.filterSettings should allow iframe and image syncs for the bidders you actually run. A blanket block to save page weight quietly lowers CPMs.
  • Sync fires after the auction, not before. Prebid delays syncs by default (syncDelay). Don't set it to zero just to "get IDs sooner". It competes with your first auction for bandwidth.
  • Prebid 10 and later block bidder endpoints from setting third-party cookies through set-cookie headers unless you allow it. This is an activity control added in Prebid 10. If a bidder's match rate dropped after an upgrade, check this before blaming the bidder.

One bidder's broken cookie can hurt everyone else. We once traced a drop in server-side matching to a single SSP writing a malformed uid cookie (invalid base64) that our Prebid Server layer then passed along. The fix was to drop that cookie instead of forwarding it. If your server-side match rates fall without a clear cause, check the cookie payloads, not only the configuration.

Keep the identity modules that earn their place

Shared ID, a first-party ID Prebid can set on your own domain, works in Safari and Firefox because it isn't a third-party cookie. Safari caps cookies set by JavaScript at seven days, so a returning Safari reader who visits less than weekly looks new each time; setting the ID from your server extends that. Email-based IDs work if you have logged-in readers and consent to use them. The test for any ID module is simple: does the bidder that reads it bid more often or higher on the traffic that carries it? If you can't answer that from your own reports, you are adding page weight on faith.

Think about Safari traffic separately

Treat Safari and Firefox as their own segment in reporting. Floors, bidder mix and even refresh behavior can reasonably differ for traffic where most bidders see an anonymous user. A floor that is right for Chrome can simply suppress fill on Safari.

What didn't change

Consent rules did not relax because cookies stayed. In the EEA and UK you still need a Google-certified CMP integrated with the TCF for personalized ads, and TC strings now have to carry the TCF 2.3 Disclosed Vendors segment. US state privacy laws keep adding GPP sections. Chrome keeping cookies changes what is technically possible, not what you are allowed to do with them.

A short checklist

  • Remove Topics, PAAPI and fledge modules and config from the wrapper and page code.
  • Confirm user sync settings per bidder, and check the Prebid 10 cookie activity control after any upgrade.
  • Report Safari and Firefox separately and review floors for them.
  • Keep identity modules only where your own data shows bid lift.
  • Stop planning around a cookie deadline. Plan around consent, page speed and demand quality, which are the things that actually move revenue this year.

Want a second pair of eyes on your setup? Talk to the Valuad AdOps team.

Talk to the team behind Israel's largest publishers

Tell us about your sites and your ad server setup, and we'll show you where the revenue is.