pixellint

Blog · Chrome cookies

Chrome kept third-party cookies. The cookieless Chrome plan is the miss.

· 10 min read

Chrome will not ship a new standalone third-party cookie prompt. Safari, Firefox, and Incognito still block them. Measurement stacks that paused CAPI waiting for Chrome 3PCD are optimizing on a browser that did not flip.

On April 22, 2025 Anthony Chavez, VP of Privacy Sandbox, said Chrome will maintain its current approach to offering users third-party cookie choice and will not roll out a new standalone prompt. Users keep Chrome Privacy and Security Settings. That is the news. It is not a new hashing rule and it is not a new pixel snippet.

The cookieless Chrome plan is the miss. Teams that froze server events until Chrome flipped are running pixel-only on the one major browser that still offers third-party cookies by default. Safari, Firefox, and Incognito already blocked those cookies. Those purchases still need a first-party click id and a server POST.

The standalone prompt did not ship

On July 22, 2024 Chavez published a different path. Instead of deprecating third-party cookies, Chrome would introduce a new experience that lets people make an informed choice that applies across their web browsing, and they would be able to adjust that choice at any time. That post is still live. It is the exploration April 22 reversed.

Digiday reported the April 22 decision as a U-turn on that July approach. The April post is more specific than a vibe: Chrome will not roll out a new standalone prompt for third-party cookies. The setting that already exists stays the setting. There is no new interstitial that would have flipped a large Chrome cohort in one week.

Chavez wrote that publishers, developers, regulators, and the ads industry still hold divergent perspectives on changes that could affect third-party cookie availability. The Privacy Sandbox initiative started in 2019. Formal engagement with the UK CMA and ICO started in 2022. The April post cites that history and then keeps the current choice model. If your roadmap assumed a forced Chrome flip, the forced flip is not on the calendar.

Incognito, Safari, and Firefox still block

The same April 22 post is explicit about Incognito. Chrome will continue to enhance tracking protections in Incognito, which already blocks third-party cookies by default. IP Protection was planned for a Q3 2025 launch at that announcement. That is Incognito, not the default Chrome profile. Treating Incognito as Chrome, or Chrome as Incognito, is how two dashboards disagree.

Safari Intelligent Tracking Prevention already blocks third-party cookies on vendor hosts. JavaScript-set first-party cookies that look like trackers also get a short life. Firefox Enhanced Tracking Protection is the same class of block for third-party cookies. Those users did not wait for Chrome 3PCD. They have been cookieless on the third-party hop for years.

A pixel that still depends on a third-party cookie on a vendor domain is already a miss in those browsers. Server events plus a click id you captured on the landing hit are how the purchase still joins. Chrome keeping third-party cookies in the default profile does not restore Safari. It does not restore Firefox. It does not restore Incognito.

Privacy Sandbox is not the measurement default

Chavez wrote that Privacy Sandbox APIs may have a different role after this update, and that Google would share an updated roadmap. Do not treat those APIs as the thing that replaced CAPI on April 22. They did not. A Topics interest or an Attribution Reporting report is not a Purchase POST.

CHIPS, FedCM, Storage Access, and User-Agent Client Hints remain on the continue-to-support list on that status page. Those are browser platform features. They are not a Meta Purchase, a Snap PURCHASE, or a Reddit event_at. If your worker only knows how to POST a conversion envelope, Chrome's cookie setting is an input to match rate, not a reason to delete the worker.

First-party cookies on your checkout host were never the thing Chrome was going to deprecate. Third-party cookies on a vendor domain were. If your join already lives in a first-party cookie you set, plus a click id you copy through redirects, April 22 did not change that design. If your join still lives only on a facebook.com cookie, Safari already taught you the outcome. Chrome keeping the third-party cookie does not make that the Safari plan.

The config people will ship first

A measurement flag that paused CAPI because Chrome was going to drop third-party cookies. Chrome did not.

{
  "browser": "chrome",
  "pixel": true,
  "capi": false,
  "reason": "resume after Chrome third-party cookie deprecation"
}

That object is a legal JSON flag. Posted as policy it is how Safari and Firefox purchases never train. Chrome can still look healthy in a pixel debugger because third-party cookies still exist for users who did not turn them off. The blocked browsers were never in that screenshot.

Dual-pipe CAPI still matters because the browsers that already flipped still block. Capture fbclid, ScCid, rdt_cid, or li_fat_id on the landing URL. Copy the value through checkout. POST the vendor envelope from the order, with the pixel event id reused so the vendor can dedupe. Chrome cookie status is not a hashing tutorial and it is not a reason to drop that hop.

Names that do not translate

The pixel still lies in opposite directions

Pixel-only undercounts people who blocked the tag, people on Safari whose third-party cookie never landed, and people whose hosted checkout never ran your script. CAPI-only still needs the click ids and first-party cookies you collected yourself, because the POST comes from your VPC, not from the shopper's browser. The documented hybrid is both pipes, same event id.

Chrome keeping third-party cookies does not close those holes. Ad blockers still eat the pixel. Hosted checkout still leaves the thank-you host without the landing cookie unless you copied it. Safari still caps tracker-like storage. The April 22 news is that Chrome did not add a new reason to pause the server pipe.

If Chrome users look cheap and Safari users look expensive after you paused CAPI, you are not measuring incrementality. You are measuring which browser still accepted a third-party cookie. That split was already true in 2023. April 22 made it the default Chrome story again, not a new Safari story.

We've made the decision 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. Users can continue to choose the best option for themselves in Chrome's Privacy and Security Settings.

Anthony Chavez, Privacy Sandbox, April 22, 2025

What to do

Keep one internal event: name, UTC instant, order id, hashed email if the vendor wants it, landing URL, click references. At the edge, emit the vendor envelope. Do not gate that POST on a Chrome cookie-deprecation flag. Chrome did not ship the flag you were waiting for.

Measure Safari, Firefox, Incognito, and default Chrome as different cuts. If the pixel is healthy only in Chrome, the server hop is the Safari hop. Persist click ids on first hit, before any clean-URL redirect. Reuse the pixel event id on CAPI so you do not double-count the Chrome users who still have the cookie.

The contract pages for cookies and the hybrid pipe are first-party vs third-party cookies, Safari ITP, and pixel plus CAPI. This post is the market fact: Chrome kept third-party cookies, and the cookieless plan is the miss. Pixellint is not affiliated with Google. Passing a linter means the artifact matches a published envelope. It does not mean Chrome attributed the order.

Checklist

Sources

Contract pages

The dated argument is above. These pages are the field lists.

Read pixel plus CAPI Docs