Safari 27 tracking protection: What it means for conversion measurement

Safari 27 dropped as a developer beta in June 2026. The official release notes cover CSS fixes and rendering improvements. We went deeper and reviewed WebKit's open-source code at github.com/WebKit/WebKit, the privacy infrastructure that actually controls how Safari handles tracking requests. Here is what we found.

This is a follow-up to our Safari 26 breakdown. If you want background on Advanced Fingerprinting Protection and how Link Tracking Protection works, start there. This piece covers what is new in 27.

Apple's official release notes for Safari 27 beta are available on the Apple developer site.

One structural change that makes everything else worse

Before the specifics, one finding from the source matters for how you read everything that follows.

Safari's privacy rules are not baked into the browser binary. Which click IDs get stripped, which scripts get restricted, which IP addresses get blocked: Apple stores all of that in a separate system library that updates independently of Safari itself. Apple can add a new tracking domain, a new click ID parameter, or a new ad network IP range to the blocklist without shipping a browser update. Any device with Safari installed can receive updated rules silently in the background.

The practical consequence is that even if Apple announces nothing about tracking in a given Safari release, the rules your campaigns run against can change at any time. The Safari 27 update expands those lists, but the next update to the lists might arrive with no public announcement.

Link Tracking Protection now covers more platforms

Safari has been stripping known tracking parameters from URLs since Safari 17. In Private Browsing, Mail, and Messages, click IDs disappear before the destination page ever loads. The list of covered parameters grows with each version.

New in Safari 27, three more platforms join the filter:

• Threads: xmt is stripped
• YouTube: si is stripped
• X (formerly Twitter): twclid, cn, and cxt are stripped

Google and Meta click IDs were already covered. Adding Threads, YouTube, and X matters for anyone running paid campaigns on those platforms.

twclid is X's primary click identifier, the same role gclid plays for Google Ads. si is a share-source and session identifier appended to YouTube share links. It is not a paid-click ID in the way twclid is, but its removal still strips source context from YouTube traffic in Safari sessions. Losing either in Safari sessions creates the same attribution gap that Google Ads advertisers already know from Safari's handling of gclid.

LTP in regular (non-private) Safari browsing is still being phased in. As of Safari 26, click IDs continued to pass through in standard sessions. Apple's pattern has been to expand the list first, then push enforcement to regular browsing in a later update. The parameters are in. Enforcement across all sessions is the logical next step.

AFP is not a binary block

Most coverage of Advanced Fingerprinting Protection describes it as "Safari blocks these scripts." The source code shows a more granular picture, and it matters for understanding which parts of your tracking actually break.

When Apple classifies a script as a fingerprinting tool, it does not simply block it. It assigns that script a specific set of permissions: a list of what the script is and is not allowed to access. The categories Apple can revoke individually include:

• URL query parameters (click IDs, UTM values)
• Referrer data (traffic source)
• Cookie access
• Local storage access
• Canvas API (a common fingerprinting surface)
• Screen size and viewport dimensions
• Hardware concurrency information
• Network requests

A classified script might lose access to URL parameters and referrer data while keeping the ability to make network requests. Or it might be restricted from canvas and audio APIs but keep cookie access. The specific impact depends on which permissions Apple revokes for that particular script.

The LinkedIn Insight Tag (snap.licdn.com) is on the fingerprinting list. For conversion tracking, the most damaging restrictions are losing query parameter access (no click ID can be read) and losing referrer data (no traffic source attribution). The script may still be able to fire a network request to LinkedIn's servers, but without the identifiers needed to match a conversion to a click, the data it sends does not connect to a campaign.

The same list includes Tealium, Segment, DPG Media, and Blueonic.

When a CDP like Tealium or Segment is classified as a fingerprinting tool, every tag it fires inherits the same restrictions. A conversion pixel deployed through a restricted CDP container loses the same access as a directly classified script.

Apple is using Chromium's own ad detection lists

The source shows that Safari's Resource Monitor, the layer that blocks entire tracking endpoints rather than just parameters, compiles its rules into the same format used by Safari content blocker extensions. The actual filter data comes from Apple's system library.

Reviewing the rules on a device with Safari 27 beta installed, the blocking patterns match filter entries from Chromium's open-source ad detection infrastructure. Apple is pulling from the same filter data that Google built and open-sourced for Chromium-based browsers.

Source: https://github.com/chromium/chromium-ads-detection

Blocking has moved below the application layer

Previous versions of Safari's tracking protection worked at the application layer. Scripts were blocked or restricted before they could execute, or network requests were blocked by domain name. Safari 27 moves part of the blocking to the network transport layer, which runs below anything on the page.

When a script tries to send conversion data, it opens a network connection to a destination server. Safari 27 intercepts that connection before it completes. Not by inspecting the request content, but by checking the destination IP address against a list of known ad network subnets.

For example, bat.bing.com is the Bing UET endpoint. It resolves to Microsoft's ad infrastructure. If Microsoft's ad server IP range is in the blocklist, the connection is cut before any data leaves the browser. It does not matter where the script originated, what domain it loaded from, or how the request was constructed.

First-party proxy setups are a common workaround where you load a tracking script from your own subdomain. That workaround does not help here. The script loads from your domain, but it still has to send its data to an ad platform's servers. Those servers have fixed IP addresses. The connection to those IP addresses is what Safari blocks.

There is also evidence in the source of a separate category of domains hardcoded as unconditionally blockable, regardless of what privacy settings the user has enabled. The mechanism is visible in the code; the specific contents of that list are not, since they live in an unpublished Apple file. Treat the existence of the category as observed and its exact scope as unverified.

Safari's blocking history, layer by layer

Each major release adds a new surface.

• 2017: ITP brought cookie restrictions and storage expiration
• Safari 17: ATFP added domain-level network blocking in Private Browsing and click ID stripping from links
• Safari 26: AFP added fingerprinting script classification in all browsing modes, with per-script permission revocation
• Safari 27: IP-range blocking at the network transport layer, an expanded click ID filter, and CDPs on the fingerprinting list

Earlier protections targeted what scripts could read or store. The network-level blocking targets where data can go. You can change a script filename, a URL path, a first-party subdomain. The IP addresses that Microsoft's or LinkedIn's ad servers are hosted on? Those do not change.

Where TAGGRS fits

Server-side GTM changes the architecture in a way that makes Safari's browser-level restrictions stop mattering. Not because it bypasses anything clever, but because the tracking requests Safari is blocking never go through the browser.

With a standard client-side setup, the browser runs the script, reads what it needs from the page, and sends the conversion request to an ad platform's endpoint. Safari's network layer sees that outbound connection and blocks it.

With sGTM, the browser sends one request to your own server, your own subdomain, your own IP. The server handles everything from there. It processes the event and forwards the data to Google, Meta, LinkedIn, or Bing through server-to-server calls that never pass through the user's browser. There is nothing for Safari to intercept.

bat.bing.com and snap.licdn.com are blocked at domain and IP level. With sGTM, your setup never calls those URLs from the browser. The connections to ad platforms happen on the server after the browser interaction is already recorded.

TAGGRS's Enhanced Tracking Script adds another layer: it encrypts the request from browser to server, which prevents ad blocker pattern matching from identifying the request as tracking traffic before it even leaves the page.

For LinkedIn, the practical move is LinkedIn CAPI through the sGTM container, replacing the Insight Tag with a server-side conversion call. For Bing, the Microsoft Ads API equivalent. Both remove the dependency on browser-side script execution that Safari is now blocking.

The advantages compound. Because the conversion request never touches an ad platform's endpoint from the browser, there is nothing for Safari's network layer to intercept, and the blocking simply has no surface to act on. 

You also get first-party data ownership: the event lands on your server first, so you control what gets forwarded and how. Load times improve, since heavy client-side tags move off the page. The setup is durable in a way browser workarounds are not. When Apple expands a blocklist or ships a new Safari release, a server-side architecture doesn't need to be re-patched, because it was never depending on browser-side execution in the first place.

What is already at risk

Safari 27 stable will ship with iOS 27 and macOS 27, expected later in 2026. The source analysis makes it possible to map the exposure before the update hits production.

YouTube and X campaigns – si and twclid are in the new click ID filter. Attribution for Safari users who click YouTube links or X ads will have gaps once LTP enforcement expands to regular browsing. YouTube is among the highest-traffic ad platforms. twclid is X's primary click identifier. Neither is an edge case.

CDPs handling conversion tags – Tealium and Segment are on the fingerprinting script list. Any conversion pixel or remarketing tag fired through a restricted CDP inherits the same access revocations. The CDP itself becomes the point of failure, not the individual tag.

LinkedIn Insight Tag and Bing UET – the Insight Tag is on the fingerprinting list with query parameter and referrer access revoked. The Bing UET endpoint is blocked at both domain level and by IP subnet. Both are confirmed from the source analysis.

First-party proxy setups – Safari's network-level blocking checks the destination IP, not the script's origin domain. A proxy on your own domain still forwards data to an ad platform's servers. The connection to those servers is what gets cut.

Every browser-based workaround, like first-party proxies, renamed scripts or new subdomains, is on the wrong side of where Safari is now blocking. Server-side tracking moves conversion data off those surfaces entirely, so there's nothing left for Safari to intercept.

If you want to see how that setup works in practice, our Safari 26 breakdown walks through the sGTM architecture in detail.

Ready to get started with Server-side Tracking? Create a free TAGGRS account. 

FAQ

Is Safari really blocking trackers?

Yes. Safari blocks at multiple layers: cookie restrictions (Intelligent Tracking Prevention), domain-level network blocking in Private Browsing (Private Browsing 2.0), fingerprinting script restrictions (Safari 26.0 release notes from WebKit), and IP-range blocking at the network transport layer in Safari 27 (confirmed from WebKit source analysis, not yet documented in Apple's public release notes). Browser-based tracking for Safari users gets less reliable with each release. Server-side setups are not affected because no tracking requests pass through the browser.

Which parameters does Safari 27 strip from URLs?

In Private Browsing and when links are opened from Mail or Messages, Safari strips a growing list of click ID parameters through Link Tracking Protection. Apple explains the mechanism there: known tracking query parameters are removed before navigation, and third-party scripts on the destination page cannot read the full URL. New in Safari 27: xmt (Threads), si (YouTube), twclid, cn, cxt (X/Twitter). Previously covered parameters include gclid, fbclid, and msclkid. For background on why click IDs in URLs matter at all, see WebKit's ITP 2.3 post on link decoration. Standard UTM parameters (utm_source, utm_medium, utm_campaign) are not affected.

Will these changes affect regular Safari browsing too?

Link Tracking Protection in regular (non-private) browsing is being phased in. As of Safari 26, click IDs still passed through in standard sessions. Safari 27 expands the filter list, but Apple tends to roll enforcement out in stages. Users can already opt into the stronger Private Browsing protections for all sessions via Advanced Tracking and Fingerprinting Protection (set to "All Browsing" in Safari settings; see Apple's Safari guide). Full enforcement across all sessions without that toggle is the direction Apple has been moving toward.

What is AFP, and does it fully block a script?

AFP (Advanced Fingerprinting Protection) classifies scripts as fingerprinting tools and applies a specific set of access restrictions to each one. It is not an all-or-nothing block. WebKit's Safari 26.0 announcement describes what gets restricted: APIs that reveal device characteristics (screen size, hardware concurrency, canvas, audio), script-written storage (cookies, localStorage), and navigational data (query parameters, document.referrer). Apple can revoke some of those while leaving others intact. The practical impact depends on which access Apple revokes for that specific script. The original Private Browsing version is explained in WebKit's Advanced Fingerprinting Protection section.

What is the difference between AFP and ATFP?

AFP (Advanced Fingerprinting Protection) restricts what classified fingerprinting scripts can access. ATFP (Advanced Tracking and Fingerprinting Protection) is the user-facing Safari setting that extends Private Browsing protections, including link parameter stripping and domain-level tracker blocking, to regular browsing when enabled. WebKit's Private Browsing 2.0 post covers both: AFP handles fingerprinting script restrictions, while the "Advanced Tracking and Fingerprinting Protection" toggle controls whether LTP and tracker blocking apply outside Private Browsing. ATFP is on by default only in Private Browsing. AFP protections expanded to all sessions in Safari 26. Apple's consumer overview of these features is on apple.com/privacy/features.