They were, and then they were not. Google spent years promising to remove third-party cookies from Chrome, then reversed course. In April 2025 Anthony Chavez, VP of Privacy Sandbox, wrote that Google had decided to maintain its current approach to third-party cookie choice in Chrome and would not roll out a new standalone prompt.
So the deadline everyone planned around simply went away. Third-party cookies still work in Chrome today, and users control them through Chrome's Privacy and Security Settings just as they did before.
That leaves a lot of teams holding half-finished migration plans. This piece covers what actually changed, what quietly got cancelled behind it, and what we think you should still do on your own website.
A first-party cookie is set by the website you are visiting. A third-party cookie is set by a different domain that your page loads, such as an ad network or an embedded widget. Because that same third domain appears on many sites, it can recognise the same browser across all of them.
That cross-site recognition is the entire point of the debate. First-party cookies keep you logged in and remember your cart. Third-party cookies build a profile of where you have been.
The distinction matters for your build, because the two behave completely differently in modern browsers. A first-party cookie on your own domain is stable. A third-party cookie is already blocked for a large share of your visitors, no matter what Chrome does.
There were three separate announcements. In July 2024 Anthony Chavez wrote that instead of deprecating third-party cookies, Chrome would introduce a new experience letting people make an informed choice across their browsing. In April 2025 he wrote that Google would keep its current approach and not roll out that standalone prompt at all.
The reason given was disagreement. Google's April 2025 post pointed to divergent perspectives across publishers, developers, regulators, and the advertising industry on changes that would affect third-party cookie availability.
Then in October 2025, Chavez published a third post confirming what that reversal meant for the technology programme built around it. That is the announcement most teams missed, and it matters more than the cookie decision itself.
Read together, the sequence tells a clear story. Google tried to replace third-party cookies, could not get agreement, and stopped. The status quo won.
No. Chrome changed its mind, but Chrome is not the whole web. Safari has blocked cross-site cookies by default since March 2020, when WebKit engineer John Wilander announced that cookies for cross-site resources are now blocked by default across the board. Firefox confines cookies to the site that created them through Total Cookie Protection.
Put numbers on that. StatCounter's worldwide browser figures for July 2026 put Chrome at 68.22 percent, Safari at 16.47 percent, Edge at 5.37 percent, and Firefox at 3.34 percent. So roughly a fifth of the market already blocks the thing Chrome decided to keep.
Mozilla describes Total Cookie Protection as giving each website its own separate cookie jar, which stops tracking companies using cookies to follow someone from site to site. It is on by default as part of Enhanced Tracking Protection.
Our read is that anyone who paused their first-party data work in 2025 made a mistake. The Chrome reversal removed a deadline. It did not restore the reliability third-party cookies had ten years ago.
Most of them were retired. In the October 2025 post, Google said it had decided to retire Attribution Reporting API on Chrome and Android, IP Protection, On-Device Personalization, Private Aggregation including Shared Storage, Protected Audience on Chrome and Android, Protected App Signals, Related Website Sets, SelectURL, SDK Runtime, and Topics on Chrome and Android.
That is ten technologies in one announcement. Several of them, particularly Topics and Protected Audience, had been the centrepiece of every agency deck about life after cookies.
Google did not publish retirement dates. The post said only that it would follow Chrome and Android processes for phasing these out and share updates as they come.
If your measurement roadmap has a line item for Topics or Protected Audience, delete it. Building on an API the vendor has announced it is retiring is a straightforward waste of budget.
A short list survived, and it is the useful part. Google said CHIPS and FedCM have seen broad adoption, including support from other browsers, and continue. Private State Tokens continue. Google also said it believes a proposed interoperable Attribution standard, being worked on through the W3C, can support scaled measurement.
CHIPS is worth knowing about if you run embedded content. It lets a third-party cookie be partitioned to the top-level site that loaded it, so a widget can keep state without becoming a cross-site tracker. If you embed a booking tool or a support widget, this is the mechanism that keeps it working in a partitioned world.
FedCM matters if you offer social or federated sign-in. It gives browsers a proper identity flow instead of relying on third-party cookies and redirects that keep breaking.
The pattern is worth noticing. The survivors are the standards that other browser makers also adopted. The casualties were the ones only Chrome shipped. That is a useful filter for the next platform proposal you are asked to build around.
For most business sites, less than you would think. If your site is a marketing site with forms, a CRM, and analytics, you were never leaning on third-party cookies for the parts that matter. Your conversion tracking, your session data, and your logged-in state all run on first-party cookies on your own domain.
Where it bites is advertising and retargeting. Audience matching across sites, view-through attribution, and frequency capping all degrade when third-party cookies are blocked, and they are already blocked for Safari and Firefox users today.
So the practical answer is to stop treating this as a compliance deadline and start treating it as a data quality question. How much of your reported conversion data actually comes back, and from which browsers?
We run that check on client sites during rebuilds, because it usually reveals that a marketing team has been comparing channels using numbers that are systematically wrong for a fifth of their audience.
Consider it, but not because of Chrome. Server-side tracking moves data collection from the visitor's browser to your own server, which makes measurement less dependent on browser cookie policy and less exposed to ad blockers. It also adds real cost and real complexity, so it is not automatic.
The honest trade-off is that server-side setups need maintenance, they can hide bugs from front-end developers, and they do not remove your consent obligations. Anyone selling it as a way around privacy rules is selling you a problem.
Our view is that it earns its keep when paid media spend is large enough that a percentage point of attribution accuracy is worth real money. Below that, a clean first-party setup does the job. We go through the mechanics in our guide to server-side tracking and whether your website needs it.
One side benefit is speed. Every tracking pixel you remove from the page is one fewer request competing with your content, which is the same reason we are strict about how third-party scripts slow a website down.
Yes, and Chrome's decision has nothing to do with it. Consent requirements come from privacy law such as the GDPR and the ePrivacy rules in Europe, not from a browser roadmap. Those laws did not change when Google changed its plan, so a site that needed consent in 2024 still needs it now.
What we would revisit is the quality of the banner rather than its existence. A lot of consent setups were bolted on in a hurry, block rendering, shift the layout, and fire tags before anyone clicks anything.
Getting that right is a build problem more than a legal one. Our notes on handling cookie consent without wrecking your site cover the parts that most often go wrong.
Three moves, in order. Delete any roadmap item built on a retired Privacy Sandbox API. Audit which of your cookies are genuinely first party on your own domain. Then check what share of your traffic comes from Safari and Firefox, because that is the portion of your measurement already running without third-party cookies.
The wider lesson we take from this whole saga is about planning. Two years of agency strategy work went into replacing a technology that was never removed, using APIs that have now been retired. The teams who spent that time improving their own first-party data instead came out ahead either way.
Build on what you control. Your domain, your forms, your CRM, and your server logs do not get cancelled in a blog post.
If you want a clear picture of how your site actually collects data, and what would break if a browser tightened the rules tomorrow, we are happy to walk through it. Let's talk at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.