For six years, the digital advertising industry rearranged itself around the premise that Google Chrome was going to kill third-party cookies. In April 2025, Google announced it wasn't. In October 2025, Google shut down most of the Privacy Sandbox APIs it had spent those six years building as replacements. The "cookieless future" as it was sold (Chrome-led, Privacy Sandbox-backed) is over.
But the actual cookieless present is already here. Safari blocks third-party cookies. Firefox blocks them. Brave blocks them. That's roughly 17 to 20% of global traffic cookieless by default, independent of anything Chrome does. And browser behavior doesn't change the legal picture: ePrivacy Article 5(3) and CCPA's sale-and-share definitions apply whether the cookie is first-party, third-party, server-side, or nonexistent.
This post is a clear-eyed read on where cookies stand in 2026: the timeline, the surviving Privacy Sandbox pieces, the real browser state, and why the legal compliance work doesn't change because Chrome kept cookies.
TL;DR. Google announced the reversal on April 22, 2025 and shut down most of Privacy Sandbox (Topics, Protected Audience, Attribution Reporting, IP Protection, Related Website Sets, and more) on October 17, 2025. Only CHIPS, FedCM, and Private State Tokens survive. Chrome keeps third-party cookies on by default; user toggles in Privacy & Security settings. Safari's ITP blocks 3PCs since 2020 and now enforces 7-day expiry on JavaScript-set first-party cookies. Firefox Total Cookie Protection partitions all cookies. Brave blocks everything. For compliance: ePrivacy Art. 5(3) applies regardless of cookie party, and CCPA "sale/share" applies to server-to-server transfers too. Chrome's reversal changes your measurement math, not your legal obligations.
The timeline
January 2020. Google's Justin Schuh announces the intent to phase out third-party cookies in Chrome "within two years."
2021 through early 2024. Multiple delays. Target slips from late 2022 to late 2023 to mid-2024 to early 2025. Each delay draws criticism from advertising trade groups (that want cookies kept) and privacy advocates (that want them removed).
July 22, 2024. Anthony Chavez, VP of Privacy Sandbox, publishes a blog post signaling a strategic pivot: instead of deprecating cookies automatically, Google will introduce "a new experience in Chrome that lets people make an informed choice that applies across their web browsing." A user-facing choice, not a default change.
April 22, 2025: the reversal. Chavez publishes the definitive announcement: "We've decided to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies." Third-party cookies stay on by default. Users manage them via existing Privacy & Security settings. The standalone prompt is scrapped.
October 17, 2025: the Privacy Sandbox shutdown. Google announces the retirement of roughly ten APIs, including the marquee ones: Topics API, Protected Audience API (the FLEDGE successor), Attribution Reporting API (Chrome and Android), IP Protection, Related Website Sets, SelectURL, On-Device Personalization, Private Aggregation and Shared Storage, Protected App Signals, and SDK Runtime. Coverage in Search Engine Land and AdExchanger. Chavez's stated reason: "low levels of adoption."
The UK Competition and Markets Authority, which had spent three years negotiating commitments from Google to limit Privacy Sandbox's market-power effects, formally closed its case following the shutdown.
What survived from Privacy Sandbox
Three components remain active:
- CHIPS (Cookies Having Independent Partitioned State): partitioned cookies that work for legitimate cross-site embeds (chat widgets, video players, embedded tools) without enabling cross-site tracking. Use the
Partitionedattribute on the Set-Cookie header. Each top-level context gets its own isolated cookie jar. - FedCM (Federated Credential Management): a browser-mediated sign-in flow that preserves the user's identity across services without exposing tracking surface to the identity provider. Relevant if you run federated auth.
- Private State Tokens: an anti-fraud signal that proves a user is trustworthy to one site based on behavior on another, without fingerprinting. Narrow use case; adoption by major bot-detection vendors is partial.
The retired APIs represented years of engineering and standardization work. Their shutdown is a real event for adtech teams that had started building on them, but most mainstream sites had not actually integrated them at scale.
The browser state that actually matters
Google's reversal describes Chrome only. The rest of the browser ecosystem already made its choices.
| Browser | Third-party cookies by default | Key mechanism |
|---|---|---|
| Chrome / Chromium | Allowed | User can disable in Privacy & Security settings |
| Edge | Allowed | Follows Chromium default |
| Safari (WebKit) | Blocked since March 2020 | Intelligent Tracking Prevention (ITP) |
| Firefox | Blocked / partitioned | Total Cookie Protection (TCP) since June 2022 |
| Brave | Blocked | Brave Shields default-on |
Safari and ITP: stricter than advertised
Apple's Intelligent Tracking Prevention has been blocking third-party cookies in Safari for nearly six years, but the less-appreciated part of ITP is what it does to first-party cookies set from JavaScript. Since ITP 2.1 (2019) and through subsequent versions, Safari enforces a 7-day expiry on first-party cookies set via document.cookie. This is why mature analytics and adtech implementations have moved to HTTP-only cookies set server-side, which bypass the JS-scoped limit.
As of Safari 26 (2025):
- Advanced Fingerprinting Protection (AFP) is on by default. Randomizes or fuzzes fingerprinting surfaces (canvas, audio context, screen dimensions in some cases).
- Advanced Tracking and Fingerprinting Protection (ATFP) is available as an opt-in in Private Browsing mode and goes further (blocks known tracker scripts by URL).
Reference: WebKit tracking prevention policy; WebKit full third-party cookie blocking announcement (2020).
Firefox and Total Cookie Protection
Firefox's Total Cookie Protection, enabled by default in Standard mode since June 14, 2022, takes a different approach. Rather than blocking third-party cookies outright, TCP partitions all cookies by the top-level site. Each site gets its own cookie jar. An embedded Facebook widget on site A sees different cookies than the same widget on site B, even though they're both "facebook.com." This prevents cross-site tracking while keeping legitimate cross-site functionality working. Mozilla announcement.
Strict mode in Firefox goes further and fully blocks known third-party trackers.
Brave
Brave Shields, on by default, blocks third-party cookies and known tracker scripts. Brave also ships Global Privacy Control enabled by default, which makes it the reference browser for testing consent implementations.
The real impact numbers
Per Statcounter Global Stats for April 2026 across all platforms:
- Chrome: 71.37%
- Safari: 14.75%
- Edge: 4.65%
- Firefox: 2.25%
- Others (including Brave): ~7%
Arithmetic: roughly 17 to 20% of global web traffic runs on browsers that block or partition third-party cookies by default. For consumer sites with meaningful iOS and Mac audiences, the Safari share alone is often 25 to 35%. For US mobile web traffic specifically, iOS Safari is over 50%.
The "cookie apocalypse" advertising trades worried about effectively already happened for roughly 1 in 5 users. For logged-out iOS web traffic, 100% of users are cookieless. Chrome keeping cookies on by default changes the measurement math for the remaining 70%, but doesn't restore the cookieful state of 2018.
Why browser behavior doesn't change legal compliance
This is the point most "cookies are back" takes miss. Chrome's decision to keep third-party cookies affects user behavior and measurement. It does not affect the legal obligations around cookies and cross-site tracking.
Under GDPR and ePrivacy
ePrivacy Directive Article 5(3) requires prior consent before storing or accessing information on a user's terminal equipment. The Directive does not distinguish between first-party and third-party cookies. A first-party analytics cookie triggers Article 5(3) the same as a third-party advertising cookie. Server-side tracking (where no cookie is set in the browser but the server observes the user via IP, headers, or first-party identifiers) is arguably also in scope under EDPB Guidelines 2/2023, finalized October 2024.
The Court of Justice's Planet49 decision established that consent under ePrivacy must be informed and affirmative. The September 2025 CNIL fines against Google (€325M) and Shein (€150M) reaffirmed that refusal must be as easy as acceptance and that cookies dropped before consent are a violation. None of these principles depend on whether the cookie is first-party or third-party.
For the full EU picture, see the GDPR Cookie Consent 2026 pillar.
Under CCPA and US state laws
CCPA's "sale" definition (Cal. Civ. Code § 1798.140(ad)) covers transferring personal information to a third party "for monetary or other valuable consideration." CCPA's "share" definition (§ 1798.140(ah)) covers transferring personal information to a third party for cross-context behavioral advertising, regardless of whether money changes hands.
Neither definition cares about the transfer mechanism. Server-side GTM forwarding to Meta Conversions API is a "share" the same as a Meta Pixel in the browser. A first-party ad platform receiving user data and then sharing it with ad-tech partners is a "share" through the ad platform. The Healthline case (July 2025, $1.55M) explicitly held that data flows through ad-tech pixels after an opt-out still constitute a violation, regardless of whether the browser sees a third-party cookie.
See the CCPA Cookie Banner Requirements pillar and The Honda, Ford, and Disney Cases.
The point
If you were hoping that Google's reversal meant you could relax on consent or opt-out handling, the answer is no. The regulatory framework is agnostic to browser mechanics. What Chrome does on its end affects how often your tags successfully drop cookies; it does not affect whether you need consent to drop them.
First-party strategies that are actually winning
With Safari, Firefox, and Brave already cookieless, and with Chrome users increasingly opting into cookie blocking via settings or extensions, the post-reversal operational state is: a growing share of traffic is cookieless whether Google decided or not. The strategies winning in this environment:
Server-side tracking
Server-side Google Tag Manager (sGTM) and similar server-to-server implementations set cookies from the server (not from the browser's document.cookie), which bypasses Safari's 7-day JS-set cookie expiry. The user's browser still sees a first-party cookie, but the expiry can be longer and the attribution window is wider.
Critical reminder: sGTM does not launder CCPA or ePrivacy obligations. If your server-side container forwards events to Meta CAPI, TikTok Events API, LinkedIn Conversions API, or any third-party destination, that forwarding is a share under CCPA and requires consent under ePrivacy. The server-side tracking guide covers the full architecture.
Authenticated traffic
The structural winners post-reversal are publishers and platforms with logged-in users. First-party identified data bypasses the cookie question entirely. Subscription-driven media, logged-in commerce, and authenticated SaaS are less affected by the cookieless shift than any ad-tech layer.
Customer Data Platforms (CDPs)
Segment, Rudderstack, Tealium, and similar CDPs aggregate first-party identified data in a server-side store and forward it to marketing destinations. This is operationally useful and a compliance risk: the forwarding is still a "share" for CCPA purposes and still requires consent under ePrivacy. CDPs make the first-party data layer efficient; they don't make it lawful on their own.
Contextual advertising
Returning to relevance: ads placed based on the content of the page rather than the user's cross-site profile. Safari's ITP and Firefox's TCP had already pushed the industry back toward contextual for non-logged-in traffic. The Google reversal doesn't change that trajectory.
Unified ID 2.0 and similar email-based IDs
The Trade Desk's Unified ID 2.0 (UID2), and similar email-hash-based identifiers, are positioned as a cookieless alternative. Adoption exists (The Washington Post, Tubi, parts of IPG and Publicis). Legal concerns are significant. In the EU, any pseudonymous identifier with cross-controller linkability is personal data under GDPR and requires a lawful basis under Art. 6 and consent under ePrivacy Art. 5(3). Class actions in the US on UID2 are pending. AdExchanger's coverage of UID2 GDPR hurdles and Neal Gerber's class-action analysis frame the risk.
What to actually do in 2026
The practical operational posture:
-
Assume 15 to 35% of your traffic is cookieless regardless of Chrome. Plan measurement and advertising around this baseline, not around a hypothetical all-Chrome audience.
-
Consent is still required. Chrome's decision doesn't affect ePrivacy Art. 5(3) for EU traffic or CCPA's sale/share rules for US traffic. A compliant cookie banner is still the foundational compliance piece.
-
Server-side is an infrastructure improvement, not a compliance workaround. Use sGTM for measurement quality and attribution, but route everything through the same consent state as client-side tags.
-
Invest in first-party identity. The durable audience asset is logged-in users. Every product decision that increases authentication rates has measurement and compliance benefits downstream.
-
Keep contextual relevance-signaling in your measurement stack. Even if you have authenticated traffic, page-level context is a durable signal that doesn't depend on browser cookie behavior.
-
For adtech integrations, audit every vendor for both consent propagation and CCPA contract terms. The Tractor Supply settlement (September 2025) cited deficient ad-tech contracts as a finding. Stale data-processing addenda are an enforcement risk.
The Privacy Sandbox lessons
Privacy Sandbox's shutdown is an instructive story. The APIs that survived (CHIPS, FedCM, Private State Tokens) are the ones that served specific legitimate functionality needs with clear user and business benefits. The APIs that died (Topics, Protected Audience, Attribution Reporting) were replacement technologies for specific adtech use cases that didn't reach adoption because the replacement was either harder to use than the thing it replaced, or didn't measurably deliver on its promise.
The general lesson: purpose-specific privacy technology wins; replacement technology for entire adtech subsystems does not. CHIPS is used because there's a specific need (partitioned cookies for embedded widgets). FedCM is used because federated auth without tracking is a clear need. Topics was proposed as a replacement for behavioral targeting, but the adtech market is not optimized for 1-of-349-categories targeting when cross-site profiles are available.
For privacy engineers, the implication is that the cleanest compliance gains come from specific, bounded privacy improvements: consent handling, GPC propagation, account-scoped opt-out, server-side tag suppression. Waiting for the industry to invent cookieless alternatives that replace the entire pipeline has not been a productive strategy.
FAQ
Are third-party cookies really coming back?
They were never really gone, and they're not "coming back" in Chrome in the sense of a formal expansion. Google is keeping the status quo: third-party cookies on by default, user can disable in settings. Safari, Firefox, and Brave continue to block them. The change is only that Chrome is not removing them by default and not introducing the planned standalone user prompt.
What replaced Privacy Sandbox?
Nothing, structurally. Google shut down most of Privacy Sandbox on October 17, 2025 without a full replacement. The surviving components (CHIPS, FedCM, Private State Tokens) address narrow, specific use cases. For broader adtech use cases, the answer in 2026 is a combination of authenticated first-party data, server-side infrastructure, contextual targeting, and (in some ecosystems) email-hash-based IDs like UID2.
Does Chrome's decision change my GDPR compliance?
No. ePrivacy Article 5(3) requires consent for any storage or access on terminal equipment, regardless of whether the cookie is first-party or third-party, and regardless of which browser the user is on. Chrome's behavior affects how often your tags succeed at setting cookies; it does not change the consent requirement.
Does server-side tracking avoid CCPA "sale"?
No. CCPA's sale and share definitions are technology-agnostic. A server-side transfer to a third party for monetary or other valuable consideration is a sale. A server-side transfer to a third party for cross-context behavioral advertising is a share. The Healthline settlement (July 2025) confirms that server-side and pixel-based flows are treated equivalently.
What about Safari's 7-day cookie expiry?
This applies to first-party cookies set from JavaScript via document.cookie. HTTP-only cookies set in Set-Cookie response headers bypass the limit. If your analytics or adtech uses JS-set cookies for long-horizon tracking on Safari, attribution past 7 days is already cut.
Should I still implement the IAB GPP string?
Yes. GPP replaced the deprecated USP string in January 2024 and is the current standard for communicating consent state to programmatic adtech vendors. Google Ad Manager reads GPP from bid requests. Implementing it is part of the standard CMP configuration in 2026. The unified implementation guide has the technical detail.
What if I was planning my adtech strategy around Privacy Sandbox?
You need to replan. Topics, Protected Audience, and Attribution Reporting are not coming back. The operational 2026 answer is the combination described above: authenticated first-party data, server-side measurement, contextual targeting, and defensible consent flows.
Does Chrome's reversal make the privacy-focused browsers less important?
Quite the opposite. Brave, DuckDuckGo, and Firefox are the browsers where privacy-conscious users go specifically because they don't trust Chrome's default. Global Privacy Control was built there; Total Cookie Protection was built there; and GPC is now legally required to honor in twelve US states. If anything, the privacy-browser share grows as Chrome's default becomes less aligned with privacy-conscious user expectations.
Is CHIPS useful for general-purpose analytics?
Not really. CHIPS partitions cookies to the top-level site, which means a cookie set in an iframe on site A is not the same cookie as one set in the same iframe on site B. For embedded widgets (chat, video), this is exactly what you want. For cross-site analytics, CHIPS doesn't help because the whole point of those analytics is to see the user across sites.
Where to go from here
The "cookieless future" headline cycle is over. The operational reality is: roughly one in five users has been cookieless for years, another slice is cookieless by choice, and Chrome's decision doesn't change the consent, opt-out, or sale/share obligations on any of them.
The practical work for privacy and measurement teams in 2026 is less about speculating on what Chrome will do and more about building the three things that actually matter: defensible consent flows that respect user choice (GDPR, CCPA, and state-specific opt-out signals), durable first-party identity for authenticated traffic, and server-side infrastructure that runs on the same consent state as client-side tags.
For the legal framework, see the GDPR Cookie Consent 2026 pillar and the CCPA Cookie Banner Requirements pillar. For the multi-state US picture, see the US State Privacy Law Tracker. For the technical orchestration of Consent Mode, GPC, and GPP, see the unified implementation guide.
If your current measurement stack is still calibrated to a deprecation that isn't happening, Consenteo's engineering team has rebuilt consent and measurement pipelines on 200+ corporate sites post-reversal. Get in touch for a conversation about where to prioritize first.
Keep reading
More from the Consenteo Knowledge Hub on this topic.
Server-Side Tracking: A Beginner's Guide
Server-side tracking moves measurement off the browser and onto your own infrastructure. A practitioner's intro: the architecture, the trade-offs, and why it is not a compliance workaround under GDPR or CCPA.
GDPR Cookie Consent in 2026: ePrivacy, Legitimate Interest, and What Actually Compliant Looks Like
The ePrivacy Regulation was withdrawn in February 2025. The CNIL fined Google €325M and Shein €150M in September 2025. The EDPB expanded the scope of Article 5(3) to pixels and fingerprinting. A practitioner's guide to GDPR cookie consent in 2026, grounded in the regulation text, the CJEU case law, and the enforcement actions that define the line.
CCPA vs. CPRA: What Actually Changed, and Why It Matters Three Years On
The California Privacy Rights Act amended the CCPA in 2020 and took effect in 2023. Three years of enforcement later, the operational differences are clear: the 'share' right, the new sensitive-PI category, the CPPA as a dedicated regulator, and the cure period's disappearance. A practitioner's read on what changed and what it costs.


