iOS 27 Link Tracking Protection and Click IDs: What Gets Stripped, Where, and How to Keep Attribution Honest

iOS 27, which Apple released on September 14, 2026, brought no documented change to where Link Tracking Protection runs. Apple still removes known tracking parameters only where it documented in 2023: links shared in Messages and Mail, and links opened in Safari Private Browsing. Normal Safari tabs strip them only if the user opts into All Browsing.

That matters because it is easy to read Apple's iOS 26 announcement as removing gclid and fbclid from every Safari visit. Apple's own release notes do not say that. This guide separates what Apple documents from what vendors report, shows how to test your own links in ten minutes, and lays out a measurement setup that stays honest whichever way Apple moves next.

Key Takeaways

• iOS 27 shipped no documented Link Tracking Protection change: the Safari 27 release notes list none. One vendor's WebKit code review reports more tracking parameters (twclid, xmt, si) added to the filter; Apple has not confirmed it.
• The documented default scope is links shared in Messages and Mail plus Safari Private Browsing. Normal Safari browsing is covered only when Advanced Tracking and Fingerprinting Protection is set to All Browsing.
• iOS 26 made advanced fingerprinting protection the default in all browsing. Per WebKit, that stops known fingerprinting scripts from reading query parameters; WebKit does not describe it removing them from the URL, and vendor tests report click IDs still arriving in normal tabs.
• Apple does not publish its parameter list. Vendor write-ups commonly report fbclid, gclid and msclkid among the removed parameters in covered contexts; treat that as an observation to test, not a spec.
• Honest attribution means capturing click IDs server-side on the first landing, sending user-provided data to Google and Meta when an ID is missing, and reporting unmatched paid traffic as unmatched instead of letting it fall into direct.

Did iOS 27 change Link Tracking Protection?

Not in anything Apple has documented. Apple's iOS 27 announcement and the Safari 27 release notes describe no change to Link Tracking Protection or to where it runs. The Safari features Apple highlighted are tab grouping, page-change alerts and custom extensions. One vendor reports the parameter list itself grew in Safari 27, which Apple has not confirmed.

The September 14, 2026 announcement describes Safari's new tools as ones that "automatically organize a user's tabs into topics; notify them of website changes, like product restocks or price drops; and enable the creation of custom extensions based on a description." Nothing in it touches link decoration. The Safari 27 release notes, which state that Safari 27 is available for iOS 27, carry no privacy entry about query parameters, and the WebKit Features for Safari 27.0 post is likewise silent on link tracking.

The confusion has a traceable source. Apple's iOS 26 announcement said "browsing in Safari gets even more private with advanced fingerprinting protection extending to all browsing by default." That line is easy to read as click IDs disappearing everywhere. The shipped Safari 26 release notes list one privacy feature: "Added support for preventing fingerprinting for known tracking scripts." An independent analysis of the Safari 26 notes also reports that a Link Tracking Protection entry seen during the beta did not make the final release, and concludes that Safari 26 does not automatically remove gclid or fbclid.

The parameter list is a separate question from where the feature runs. A July 2026 review of WebKit's open-source code by the tag-management vendor TAGGRS reports that the Safari 27 cycle added Threads (xmt), YouTube (si) and X (twclid, cn, cxt) parameters to the filter, that Google and Meta click IDs were already covered, and that click IDs still passed through in standard Safari 26 sessions. Apple's release notes mention no list change, so treat it as a lead to test rather than a documented fact.

Where does Link Tracking Protection apply on iPhone?

By default it applies in three places: links shared in Messages, links shared in Mail, and pages opened in Safari Private Browsing. Normal Safari tabs keep the full URL unless the user switches Advanced Tracking and Fingerprinting Protection to All Browsing. Apple's documentation does not describe the feature running anywhere else, so any other surface is something to test.

Apple's privacy features page describes the Messages behavior in plain terms: "When you share links in Messages, the extra information that some websites add to their URLs will be removed to prevent them from tracking you or the person you shared the link with." Apple's Safari User Guide for Mac says that "when you use Private Browsing, 'Use advanced tracking and fingerprinting protection' is turned on by default," that the setting means "known tracking parameters are removed from all URLs," and that "you can turn this setting on for all browsing." On iPhone, WebKit's Private Browsing 2.0 post gives the path: Settings, Apps, Safari, Advanced, Advanced Tracking and Fingerprinting Protection, then All Browsing.

Scale matters here. Safari held 52.84% of US mobile browser share in August 2026, per Statcounter, so more than half of US mobile browsing happens in a browser where these rules apply. What share of those clicks happen in Private Browsing, or on devices switched to All Browsing, Apple does not publish. That number is yours to measure, and the method is below.

Which parameters get removed: gclid, fbclid, or UTM tags?

Apple does not publish the list. WebKit's stated rule is that Safari removes query parameters "identified as being used for pervasive cross-site tracking granular to users or clicks." Per-click IDs such as fbclid, gclid and msclkid fit that description, and vendor write-ups report them removed in covered contexts. Campaign-level UTM tags do not fit it and are reported as kept.

The rule comes from WebKit's Private Browsing 2.0 write-up, which explains that "Safari removes a subset of query parameters that have been identified as being used for pervasive cross-site tracking granular to users or clicks," and that the parts of the URL covered "are query parameters and the fragment." It does not name the parameters. Everything more specific you read, including lists that put gclid, fbclid, msclkid, dclid and mc_eid on the removed side and the Safari 27 review that adds twclid, xmt and si, comes from third-party write-ups such as Fathom Analytics' iOS 17 guide, and they do not always agree: the analysis cited above concludes that normal Safari 26 browsing leaves gclid and fbclid in place, which is consistent with Apple's own documentation of an opt-in setting.

Two practical readings follow. First, a click ID you depend on is at risk only in the contexts listed in the previous section, and only if Apple's private list includes it. Second, because the list can change without a release note, the only durable answer for your account is a test on your own links, repeated after each iOS update.

What does iOS 26 fingerprinting protection do to query parameters?

It hides them from certain scripts without removing them from the address. WebKit says Safari 26 "prevents known fingerprinting scripts from reading state that could be used for navigational tracking, such as query parameters and document.referrer." WebKit scopes the restriction to known fingerprinting scripts, so check your server log to see whether the click ID arrived; a third-party script on Apple's fingerprinting list may not see the click ID.

This distinction predicts a specific symptom: the click ID is present in server logs or in a first-party form handler, yet a third-party tag records the same visit without it. According to the WebKit Features in Safari 26.0 post, the same protection also stops those scripts from reading screen dimensions, hardware concurrency, 2D canvas and web audio readback, and from setting long-lived script-written storage such as cookies or LocalStorage. If a vendor's script is on that list, the fix is not a new URL format. It is reading the click ID with first-party code and passing it to the vendor server-side.

How do you test what your own links lose?

Send one tagged test URL through every context and compare what arrives at your server. Use a page on your own domain, add dummy values for each click ID you use plus UTM tags, and log the raw request URL server-side, because a browser tag can be blinded by fingerprinting protection even when the parameter reached the page.

1. Build a test link such as https://www.example.com/lp?gclid=test1&fbclid=test2&msclkid=test3&utm_source=test&utm_medium=cpc&utm_campaign=ltp-check, pointing at a page you control.
2. On an iPhone running iOS 27, note the value under Settings, Apps, Safari, Advanced, Advanced Tracking and Fingerprinting Protection.
3. Open the link five ways: a normal Safari tab, a Private Browsing tab, from a Messages thread, from a Mail message, and once more in a normal tab after switching the setting to All Browsing.
4. For each visit, read the query string your web server or edge logged, then read what your analytics tag and ad pixels recorded for the same visit.
5. Record the iOS version, the setting and the result per parameter. Re-run after every iOS point release, since the parameter list can change without a release note.

A parameter missing from the server log was stripped from the URL. A parameter present in the server log but missing from a vendor tag was blocked at the script level. The two need different fixes, so it pays to know which one you have.

How do you keep paid attribution honest when click IDs go missing?

Stop treating the click ID as the only join key. Capture it server-side on the first landing when it exists, send hashed user-provided data to Google and Meta when it does not, keep UTM tags on every paid link, and label paid sessions that arrive without an ID as unmatched rather than letting them fall into direct or organic.

Capture the click ID once, first-party

Read gclid, gbraid, wbraid, fbclid and msclkid from the landing URL in first-party code, store them with the session, and copy them into hidden fields on lead forms so they reach your CRM. This also sidesteps the script-level blocking described above, because your own code, not a third-party tag, is doing the reading.

Google Ads: send conversions even without a gclid

Google's offline conversion documentation lists gbraid and wbraid, parameters for ad clicks between iOS apps and the web, alongside the gclid, and adds user identifiers and session attributes for enhanced conversions. Its guidance on missing IDs is direct: "you can, and should, send all relevant data for a given conversion, even if you don't have a GCLID for it. Conversions that include only user-provided data are still useful and can contribute positively to campaign optimization."

Meta: send fbc when you have it, events either way

Meta builds its fbc click value from the fbclid parameter, and its Conversions API documentation says "we recommend sending the fbc parameter with every event you send to the Conversions API." When fbclid never arrives, there is no fbc to send, so the server-side event has to carry the other matching data you collect with consent.

Report the gap instead of hiding it

Add an explicit state to your channel model: a session tagged utm_medium=cpc with no click ID is paid but unmatched. Trend that share by browser and iOS version. If it jumps after an iOS release, you have measured your exposure instead of guessing it, and you can calibrate click-based numbers against aggregate methods such as incrementality tests and the model comparisons in our multi-touch attribution guide.

Know Apple's own alternative

Apple's answer to the loss of URL tracking is privacy-preserving click measurement. WebKit says it "expanded Web AdAttributionKit (formerly Private Click Measurement) as a replacement for tracking parameters in URL to help developers understand the performance of their marketing campaigns even under Private Browsing." It is designed to measure campaigns without cross-site tracking, so it complements click-ID attribution rather than replacing it one to one.

What should a paid media team do this week?

Run the five-context link test on one live campaign URL, confirm your forms capture click IDs server-side, turn on enhanced conversions and Conversions API if they are off, and add a paid-but-unmatched metric to your weekly report. None of this depends on guessing Apple's private parameter list.

FAQ

Does iOS 27 strip gclid from Google Ads clicks?

Not in a normal Safari tab by default, according to Apple's documentation. In Safari Private Browsing, in links shared through Messages or Mail, and in normal tabs when the user has chosen All Browsing, Safari removes known tracking parameters. Apple does not publish whether gclid is on its list; vendor tests often report that it is, so test your own links.

Does Link Tracking Protection remove UTM parameters?

Apple does not say so. WebKit describes the removed parameters as ones used for tracking "granular to users or clicks," and campaign-level UTM values are the same for every visitor to a campaign, so they fall outside that description. Third-party testing generally reports UTM tags kept, which is why they remain the safest fallback for channel reporting.

How do users turn Link Tracking Protection on for all Safari browsing?

On iPhone, open Settings, then Apps, Safari, Advanced, and set Advanced Tracking and Fingerprinting Protection to All Browsing. On a Mac, the equivalent option is in Safari settings under Advanced. Apple's guide notes that some website features may be affected when this protection is on.

Does Link Tracking Protection affect Chrome or other browsers on iPhone?

Apple's documentation covers links shared in Messages and Mail and browsing in Safari. It describes the Messages and Mail behavior as removing tracking information from the shared link itself, but it does not describe the feature running inside other browsers or in-app browsers. Treat those as untested until your own link test shows what arrives.

What should I send to Google Ads when gclid is missing?

Send the conversion anyway. Google's offline conversion documentation lists gbraid and wbraid for clicks that cross between iOS apps and the web, and says conversions that include only user-provided data, such as a hashed email address collected with consent, are still useful for campaign optimization.

What is Web AdAttributionKit?

It is Apple's privacy-preserving ad measurement for the web, formerly called Private Click Measurement. WebKit positions it as a replacement for tracking parameters in URLs that helps developers understand campaign performance in a privacy-preserving way, including under Private Browsing, rather than tying a conversion to one identifiable click.