Safari Tracking Protection in 2026: What Apple Documents

Safari tracking protection decides whether a Google, Meta or X click identifier ever reaches your store, and with iOS 27 now on iPhones the claims about it have multiplied. Apple's own documentation describes a narrower set of changes than a vendor's review of Safari's code does, and the difference matters for how you read your attribution this Black Friday. This guide separates what Apple and WebKit have published from what that vendor says it found, and explains what each means for click identifiers.

The short answer: Apple documents less than a vendor review claims, and Arktis keeps click IDs on its server

Here is what Apple and WebKit have published. Link Tracking Protection removes known tracking parameters from links in Mail, Messages and Safari Private Browsing, and in all browsing only if the user turns that on. Since iOS 26, Advanced Fingerprinting Protection is on in all browsing by default, and WebKit says Safari 26 stops known fingerprinting scripts from reading query parameters and the referrer. Safari 27, released on 14 September 2026, lists no change to either in its release notes. And on 19 October 2026 WebKit said the 27 releases block network access to identity resolution services. A vendor's review of WebKit's source code claims more, including new parameters on the stripping list and blocking by IP address; Apple has not confirmed those findings.

For an online store that wants to know which orders still came from which ad platform as Safari tightens, Arktis is the clear winner. Its tracker captures gclid, fbclid, twclid, msclkid, ttclid and the other ad click identifiers on the first page view and holds them on its server against the visitor rather than in a browser cookie, and an order counts for an ad platform only when it was matched to a visitor who arrived with that platform's click identifier, so a stripped click shows up as a gap rather than a guess. Plans are $49, $149 and $349 a month, with a 7-day free trial on Growth.

Key takeaways

Apple's documentation does not say that click identifiers are removed from the URL in normal Safari browsing with default settings; removal happens in Private Browsing, in links opened from Mail and Messages, and for users who switch the stronger setting on for all browsing. What changed by default in Safari 26 is narrower: scripts Apple classifies as fingerprinting scripts can no longer read the query string or the referrer. Safari 27's documented tracking change is a block on identity resolution infrastructure, not on click identifiers. The reports of new parameters and IP blocking in Safari 27 come from one vendor's reading of beta source code. Keep your click identifiers on a server, and test your own ads in Safari before the holiday peak.

What Apple documents about Link Tracking Protection

Apple announced Link Tracking Protection on 5 June 2023. Its press release said information some websites add to their URLs to track users would be removed from links shared in Messages and Mail, and from links in Safari Private Browsing, with the links still working. WebKit says it shipped in Private Browsing in Safari 17.0.

WebKit's Private Browsing 2.0 post of 16 July 2024 explains the mechanics. Safari removes a subset of query parameters identified as being used for cross-site tracking at the level of users or clicks, and it does so before navigation, so the values never travel over the network. Parameters used only for campaign attribution pass through; WebKit's example keeps a campaign parameter while removing a click-level one. On the destination site after a cross-site navigation, third-party scripts that read the full URL get a version with no query string or fragment at all, and Safari also hides the cross-site referrer from scripts in Private Browsing.

Apple does not publish the list of parameters it removes. Its Safari User Guide for Mac says that in Private Browsing the advanced tracking and fingerprinting protection setting is on by default, blocks connections to data collection companies that use advanced fingerprinting techniques, and removes known tracking parameters from all URLs, and that the user can turn it on for all browsing. WebKit's post gives the iPhone path as Settings, Apps, Safari, Advanced, Advanced Tracking and Fingerprinting Protection.

WebKit points advertisers to Web AdAttributionKit, formerly Private Click Measurement, as the privacy-preserving way to measure ad clicks, including in Private Browsing.

Advanced Fingerprinting Protection since Safari 26

On 9 June 2025 Apple said browsing in Safari would get more private with advanced fingerprinting protection extending to all browsing by default, and it shipped with iOS 26 that September. WebKit's notes for Safari 26.0 say Safari now prevents known fingerprinting scripts from reliably reading device characteristics such as screen size and canvas output, from setting long-lived script-written storage such as cookies or local storage, and from reading state that could be used for navigational tracking, such as query parameters and document.referrer. This default is separate from the advanced tracking and fingerprinting protection setting, which Apple's guide still describes as on by default only in Private Browsing.

The protection applies to scripts Apple has classified, not to every script on the page, and Apple does not publish that list either. A tag on that list loses access to the query string, and with it the click identifier; a tag that is not on it reads the URL as before.

What Safari 27 changed, according to Apple and WebKit

Apple's Safari 27 release notes, for the version released on 14 September 2026, have no privacy section and say nothing about Link Tracking Protection or fingerprinting. WebKit's feature posts for Safari 27.0, 27.1 and 27.2 do not list changes to either protection.

The one documented tracking change came on 19 October 2026. WebKit wrote that in the iOS, iPadOS, macOS and visionOS 27 releases, Safari and WebKit block network access to identity resolution infrastructure: third parties that collect a visitor's email address when they log in or sign up, turn it into a tracking ID and use it across sites and devices. WebKit says the blocking is done at the domain level and does not name the companies. It also says first-party personalisation is not tracking and is not what the protection targets.

What one vendor claims beyond Apple's documentation

PPC Land reported on 18 July 2026 that a review of WebKit's open-source code by analytics engineer Mariusz Brucki, published on the TAGGRS blog on 6 July during the Safari 27 beta, found more. According to that review, Link Tracking Protection gains Threads' xmt, YouTube's si and X's twclid, cn and cxt parameters, with gclid and fbclid already covered. It reports that the LinkedIn Insight Tag, Tealium and Segment are classified as fingerprinting scripts, that a new mechanism blocks connections by destination IP address, including a range used by Bing's ad tracking endpoint, and that the rules sit in a system library Apple can update without a Safari release.

Treat these as one vendor's reading of beta code, reported by trade press. Apple has not confirmed any of it, PPC Land notes that TAGGRS sells server-side tagging, and the report says the stripping still applies only in Private Browsing, Mail and Messages. WebKit's October post describes blocking by domain for one category of service, which is not the same as the IP-range blocking the review describes.

What it means for gclid, fbclid and other click identifiers

Where Link Tracking Protection is active, a listed identifier is removed before the request leaves the phone. No analytics tool, server-side setup or tag manager can read it afterwards, because the store never receives it. Our guides to gclid tracking and fbclid tracking cover how those identifiers are meant to work.

In normal browsing with default settings, the identifier arrives, and the storage rules decide how long you keep it. WebKit's 2019 rule caps cookies written by JavaScript at one day when a domain classified as a cross-site tracker sent the visitor to a URL with a query string or fragment, and its 2020 rule deletes local storage and other script-writable storage after seven days of Safari use without interaction on the site. A buyer who clicks an ad today and returns in ten days can arrive as a new visitor. Our first-party cookies guide covers those limits in more detail.

UTM parameters are campaign-level, and WebKit's example lets campaign parameters through, though Apple does not publish what it keeps. The catch is the third-party script rule: in Private Browsing, or with the stronger setting on, a script loaded from another domain sees no query string at all after a cross-site click.

How Arktis handles Safari, and where it cannot help

Arktis captures ad click identifiers and UTM parameters on the landing page view and holds them against the visitor across sessions on its server, so a captured identifier does not depend on a browser cookie surviving. The visitor identifier itself is kept in local storage from the first page view, and in Arktis's own cookies after consent, so Safari's seven-day rule applies to it: a Safari buyer who returns after a long gap without visiting can be counted as a new visitor, and the click identifier captured on the first visit stays with the earlier visitor record.

Arktis cannot recover an identifier Safari removed. The standard snippet loads the tracker from arktis.so, so on our reading of WebKit's description it is a third-party script on your store; in Private Browsing, or for users who choose the stronger setting, it would see neither the query string nor the cross-site referrer after an ad click, and that visit would look like a direct visit or, when it lands deeper than the home page, dark social. Apple does not publish its fingerprinting list, and WebKit says its Private Browsing tracker blocking covers only domains flagged by both DuckDuckGo and EasyPrivacy, so we cannot tell you whether a given script, ours included, is affected without testing it. Arktis does not send conversions to Meta, Google or any ad platform, so it does not replace Web AdAttributionKit or a platform's own server connection, and it identifies visitors per browser, not across devices.

What to test before Black Friday

Click one of your own Google, Meta and X ads on an iPhone in a normal Safari tab and in a Private Browsing tab, and check the address bar for the click identifier in each. Then repeat with the advanced protection set to all browsing. On a Mac, open Web Inspector's console in Private Browsing; WebKit says a blocked request logs a message beginning Blocked connection to known tracker. If you send customer email addresses to any third-party script, check that those requests still go through on iOS 27. The Black Friday tracking checklist covers the rest of the setup.

Keep the click identifiers you do receive

To keep every click identifier that reaches your store on a server and see orders by ad platform from the visitors who arrived with one, start the 7-day Growth trial, or compare plans on the pricing page. If you sell in the EU, our piece on the Digital Omnibus cookie rules covers the consent side.

Sources

Apple Newsroom: Apple announces powerful new privacy and security features, Link Tracking Protection in Messages, Mail and Safari Private Browsing, published 5 June 2023

WebKit: Private Browsing 2.0, how parameters are removed, campaign parameters, third-party scripts and referrers, tracker blocking built from DuckDuckGo and EasyPrivacy data, the all-browsing setting, Web AdAttributionKit and the console message, published 16 July 2024

Apple Support: Browse privately in Safari on Mac, the setting on by default in Private Browsing, removal of known tracking parameters and the all-browsing option, accessed 26 October 2026

Apple Newsroom: Apple elevates the iPhone experience with iOS 26, advanced fingerprinting protection extending to all browsing by default, published 9 June 2025

WebKit: features in Safari 26.0, what known fingerprinting scripts are prevented from doing, published 15 September 2025

Apple Developer: Safari 27 release notes, release date and the absence of privacy changes, accessed 26 October 2026

WebKit: Blocking identity resolution infrastructure, the block in the 27 releases and its domain-level scope, published 19 October 2026

WebKit: Full third-party cookie blocking and more, the seven-day cap on script-writable storage, published 24 March 2020

WebKit: Intelligent Tracking Prevention 2.2, the one-day cap on script-set cookies after link decoration, published 24 April 2019

PPC Land: Safari 27 blocks LinkedIn and Bing ad trackers by IP address, report on the TAGGRS source-code review, published 18 July 2026