pixellint

Blog · Safari ITP

Safari still blocks third-party cookies. Chrome keeping them did not unbreak Safari purchases.

· 10 min read

Chrome keeping third-party cookies is not a Safari fix. WebKit still blocks third-party cookies by default. A Meta pixel that only fires in Chrome looks healthy in Pixel Helper and still misses Safari checkout. Dual-pipe CAPI is the Safari hop, not a Chrome feature flag.

April 22, 2025, Google said it would maintain the current approach to third-party cookie choice in Chrome and would not roll out a new standalone prompt. Users can still pick a preference in Chrome's Privacy and Security Settings. That sentence traveled as Chrome un-deprecated cookies. Safari was not in the room. WebKit's tracking prevention page still describes full third-party cookie blocking as shipping behavior, with no exceptions except Storage Access API and a temporary popup compatibility fix.

A purchase that attributes in Chrome and vanishes in Safari is not a Pixel Helper bug. It is two browsers. Chrome's news did not unpartition Safari storage, did not restore third-party Set-Cookie on facebook.com, and did not stop ITP from treating classified domains as trackers. The hop that still sees the Safari order is the server POST, not a Chrome flag.

What Chrome actually said in April 2025

I am not going to rehash the whole Chrome post. The live Privacy Sandbox note is short. Anthony Chavez, April 22, 2025: keep offering users third-party cookie choice, no new standalone prompt. Incognito already blocks third-party cookies by default. IP Protection was planned for Incognito in Q3 2025. An updated Privacy Sandbox API roadmap would come later. The earlier 2024 path of deprecating third-party cookies in Chrome is not the current Chrome plan.

That is a Chrome decision. It does not bind WebKit. Firefox and other browsers were already on their own default-block paths; I am not going to quote numbers I did not fetch from those vendors. The Safari problem on a typical US retail stack was never 'Chrome will turn cookies off next quarter.' It was that Safari had already restricted cross-site trackers, and the pixel QA lived in Chrome.

Safari's default is not Chrome's setting toggle

WebKit's default cookie policy, in effect since Safari 1.0, disallows a third party from setting new cookies unless it already has cookies. To use cookies at all as a third party, the domain first has to become first-party and set its initial cookies there. That policy is still part of Prevent cross-site tracking. ITP then goes further: by default it blocks all third-party cookies. There are no exceptions to that blocking except Storage Access API and the temporary popup compatibility fix. Cookie blocking latch mode applies the block through redirects of that request.

Third-party LocalStorage and IndexedDB are partitioned per first-party website and made ephemeral. Third-party Service Workers are partitioned, including their cache and IndexedDB. Third-party HTTP cache entries are partitioned per first-party. Partitioning means adtech.example under news.example is not the same storage as adtech.example under shop.example. Chrome keeping an unpartitioned third-party cookie jar does not give Safari a shared jar.

Private Browsing uses an ephemeral session per tab. It is a different isolation from ITP in a normal window. QA that 'works in Safari' in a long-lived profile with first-party interaction is not the same as a checkout hop from a classified tracker domain the user never visited as first-party.

ITP still treats pixels as trackers

ITP classifies registrable domains that match known cross-site tracking patterns: third-party subresources under many first parties, third-party iframes, cross-site redirects, bounce tracking, and tracker collusion through redirect graphs. I am not going to invent the current exact day caps as if they were a Safari 19 release note. WebKit's tracking prevention page documents shipping behavior including a 30-day deletion of website data for classified domains with no first-party interaction and no Storage Access grant, a 24-hour cap on JavaScript cookies created after detected link decoration, a 7-day cap on script-writable storage after no user interaction, and a 7-day cap on cookies set via third-party CNAME or IP cloaking. Those are the page's numbers. Safari continues to restrict cross-site trackers even if a given cap is tuned later.

Link decoration is the click-id path. ITP detects click IDs as URL parameters, then caps expiry of cookies created in JavaScript on the landing page. A Meta pixel that writes _fbc from fbclid in page JavaScript is exactly that pattern. Chrome may keep that cookie for a long time. Safari may not. Hosted checkout on another registrable domain then loses the first-party cookie unless you copied fbclid through the redirect. CAPI still needs the value on the server event.

Referrers for third-party requests are downgraded to origins. HSTS is not applied to third-party requests that do not carry cookies, and third-party cookies are blocked, so third-party HSTS is blocked. Full third-party cookie blocking is the default, not a Chrome origin trial you forgot to enroll. Pixel Helper, running in Chrome, will not show you that Safari request. It never left the Chrome profile.

The check people will trust first

A Chrome Pixel Helper pass. It is not a Safari purchase, and it is not a CAPI event.

fbq("track", "Purchase", { value: 42.00, currency: "USD" });
// Pixel Helper: Purchase seen. Chrome, third-party cookies allowed.

That call can be a legal browser event. In Chrome with third-party cookies allowed, _fbp and _fbc may exist, facebook.com may see cookies on the pixel request, and Events Manager can look healthy. The same page in Safari sends a third-party request with cookies blocked. Partitioned, ephemeral third-party storage does not carry the identity across sites. The purchase still happened. The pixel hop did not.

CAPI is not a Chrome consolation prize. It is a POST from your origin with event_name, event_time, event_id, and match keys you already have: hashed email, click id copied from the landing URL, IP and UA in the clear. Dedup against the browser event when Safari did send one. When Safari did not, the server event is the only event. Dual-pipe is the Safari architecture. It is not 'wait until Chrome ships the prompt they cancelled.'

Names that do not translate

CAPI is the hop Safari cannot third-party

The pixel runs in the browser. Safari can block its third-party cookies, partition its storage, cap the first-party JavaScript cookie you used as a click-id jar, and delete classified tracker data after enough days without first-party interaction. The thank-you page can still POST to your server. Your server can still POST to Graph with user_data you collected first-party: email at checkout, ndclid or fbclid you copied, event_id you minted on the page or the order id.

That is the same dual-pipe every other vendor is selling, including Nextdoor CAPI and OpenAI Ads CAPI. The Chrome April 2025 note does not make the browser hop sufficient. It makes Chrome QA even more misleading, because the dominant test browser kept the cookie model the pixel was designed for. Safari did not.

Home-screen web apps are documented as exempt from ITP's 7-day cap on script-writable storage for that first-party domain, and isolated from Safari's tracker classification. That is not your paid social checkout. Do not tell a retailer to add to Home Screen instead of sending CAPI.

What QA has to include

Open the checkout in Safari with Prevent cross-site tracking on, which is the default. Confirm whether the pixel request carries cookies. It should not, as a third party. Confirm whether your first-party click-id cookie is still present at purchase. Confirm the server POST still has event_id and the click id. Repeat in Chrome only as a control, not as the release gate.

If Events Manager is green and Safari share of sessions is real, look at the browser-versus-server breakdown. A pixel-only integration that matches Chrome and under-reports Safari is working as WebKit designed. Adding another browser pixel will not unbreak ITP.

ITP by default blocks all third-party cookies. There are no exceptions to this blocking. Third-party cookie access can only be granted through the Storage Access API and the temporary compatibility fix for popups.

WebKit tracking prevention

What to do

Keep the browser pixel for Chrome and for the Safari hits that still fire. Add the server pipe with the same event_id. Copy click ids on the landing hit, not from a third-party cookie at checkout. Hash email the way the vendor asks. Do not wait for a Chrome prompt that Google said it would not ship.

Do not treat a Pixel Helper screenshot as Safari coverage. Lint the CAPI body you POST. The Safari ITP doc is the browser fact. This post is the market fact: Chrome's April 2025 choice did not unbreak Safari purchases.

Pixellint is not affiliated with Apple, Google, or Meta. Passing a linter means the artifact matches a published envelope. It does not mean Events Manager attributed the Safari order, and it does not detect fraud.

Checklist

Sources

Contract pages

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

Read Safari ITP Docs