iOS Link Tracking Protection: What It Strips and What Survives

Apple’s Link Tracking Protection removes known click identifiers from URLs. Your UTM parameters survive it.

That is the whole headline, and it means most of the attribution loss teams blame on Apple is caused by something else: cookie lifetimes, ESP redirects, or in-app browsers.

The detail that matters more than the strip list is scope. By default this runs in exactly three places, and a single setting can widen it to every Safari session.

TL;DR

• By default, stripping happens in Mail, Messages and Safari Private Browsing. Regular Safari is untouched, as are Chrome on iOS and every in-app browser.
• That default is a setting, not a boundary. Settings, Safari, Advanced, Advanced Tracking and Fingerprinting Protection offers Off, Private Browsing and All Browsing.
• Apple publishes no strip list. Every list in circulation is community testing, so treat any claim that Apple’s docs are authoritative as wrong.
• gclid, fbclid and msclkid are the three most consistently reported as stripped. All six utm_* parameters survive.
• Whether Safari 26 changed the default is genuinely disputed, and the dispute traces to Apple’s own press wording.
• Diagnose before you mitigate. Cookie expiry, ESP redirect rewrites and in-app browser sandboxes explain most “iOS broke our attribution” reports.

The Scope Is Narrower Than the Panic

Apple shipped Link Tracking Protection with iOS 17 in September 2023. When a user taps a link in one of the covered contexts, iOS removes parameters it recognises as click identifiers before the page loads.

Three contexts by default:

1. Mail, when a user taps a link in an email.
2. Messages, for SMS, MMS and iMessage.
3. Safari Private Browsing, for clicks and pasted URLs.

Where it does not run by default: regular Safari, which is where most iOS traffic lands. Third-party browsers such as Chrome, Firefox and Edge, which have their own behaviour and their own lists. In-app browsers inside Instagram, TikTok, LinkedIn, Slack, Gmail and Outlook, which open links in their own web view. And Universal Links that hand off to a native app, where the URL arrives intact.

So a paid social click that opens in Instagram’s in-app browser is untouched. The fbclid arrives. The UTMs arrive. If attribution is broken on that traffic, the cause is the app’s cookie jar, not Apple’s stripping.

Where it genuinely bites: cold email opened in Mail, SMS campaigns opened in Messages, and the slice of your audience that browses privately.

The Default Is a Setting

Plenty of published guidance, including the earlier version of this page, says there is no way to turn this off. That is wrong, and it matters for how you read your own data.

The control is at Settings, then Safari, then Advanced, then Advanced Tracking and Fingerprinting Protection, and it has three states:

• Off, which disables the behaviour, Mail and Messages included.
• Private Browsing, the default.
• All Browsing, which applies stripping to regular Safari too.

Two consequences. A user who picks All Browsing loses click identifiers everywhere, so “never in regular Safari” is true of the default and not of the capability. And a user who picks Off keeps them everywhere, which is why your own device tests can disagree with a colleague’s.

What Gets Stripped

Apple has never published the list. Everything in circulation comes from black-box testing: send URLs with known parameters through each context and see what survives. PrivacyTests.org is the most cited source.

Parameter	Origin	Reporting
gclid	Google Ads	Reliably reported
fbclid	Meta Ads	Reliably reported
msclkid	Microsoft Ads	Reliably reported
dclid	Display & Video 360	Reliably reported
twclid	X Ads	Reliably reported
mc_eid	Mailchimp	Reliably reported
gbraid, wbraid	Google Ads (iOS)	Inconsistent across releases
li_fat_id	LinkedIn Ads	Inconsistent across releases
ttclid	TikTok Ads	Not on current lists
yclid	Yandex	Occasionally reported

What survives, and structurally should:

• All six UTM parameters: utm_source, utm_medium, utm_campaign, utm_term, utm_content, utm_id.
• Generic parameters such as ref and source.
• Any custom parameter you invent.
• Anything in the URL path.

The reason is the criterion. Stripping targets parameters that identify a person across sites. UTMs identify a campaign, so they fall outside it, and nothing in the public record suggests that is changing.

The Safari 26 Dispute, Stated Honestly

Sources disagree about whether Safari 26 and iOS 26 extended stripping to regular browsing by default, and the disagreement is worth understanding rather than resolving by picking a favourite.

One camp, including WITHIN and several martech blogs, reports that protection now extends to all Safari browsing by default. None cites an Apple source.

The other camp, including lapcatsoftware, TAGGRS and Singular, reports the default unchanged from Safari 18.

The confusion traces to Apple’s own wording. Apple’s press material describes advanced fingerprinting protection extending to all browsing by default, which is a different feature from the tracking-and-fingerprinting setting that governs link stripping. WebKit’s Safari 26 release notes describe fingerprinting protection and mention no query-parameter stripping at all.

So the honest position: the default appears unchanged, the claim that it changed is widespread and unsourced, and the setting to widen it has existed since iOS 17 either way. Check your own traffic rather than trusting either camp.

Keep Attribution Working

Each pattern below stands alone. Take the ones that match your stack.

Google Ads: use the Final URL Suffix. Set it at account level under Admin, Account settings, Tracking, and every destination URL carries your UTMs alongside the auto-tagged click ID. When gclid is stripped in Mail, campaign attribution still arrives in your analytics. You lose Google’s user-level join for that click, which offline conversion import and Enhanced Conversions partly recover.

Meta and LinkedIn: tag at the ad level. Never rely on fbclid or li_fat_id as your only campaign signal. Meta’s URL parameters field takes macros such as {{campaign.name}} and {{ad.name}}, and LinkedIn supports parameters at account, campaign and ad level. Both conversion APIs do the user-level join server-side, which does not depend on the click identifier surviving the click.

Email: capture the identifier at the redirect. Mail is the context stripping actually runs in, so stop depending on the destination URL. Your ESP already routes clicks through a redirect, so capture the identifier there, write it to a first-party cookie, and send the user on with UTMs in the query string.

One detail teams miss: point the redirect at a subdomain of your own site so the cookie is readable on the destination. And know the limit. Since Safari 16.4, a server-set cookie is capped at 7 days when the subdomain is a CNAME to a third-party host or its IP sits outside your site’s range, which is exactly how most managed redirect domains are configured.

High stakes: put it in the path. /lp/2026-q2-launch/email-warmup-3 survives every stripping rule anywhere, because no privacy tool removes path segments. The cost is a route handler and parsing logic, so reserve it for campaigns that must reconcile.

Consider a team running a cold email sequence who want to know which warmup step converted. Their identifier lives in a parameter the strip list covers. Moving capture to the redirect solves it: the token is recorded server-side, the destination carries UTMs plus a custom parameter nobody strips, and reporting keys off those. Governing the values is what keeps them meaningful later, which is the job Terminus, the marketing taxonomy governance platform does at link creation.

Three Things Blamed on Apple That Are Not Apple

Cookie expiry. Safari’s Intelligent Tracking Prevention caps JavaScript-written cookies at 7 days, and at 24 hours when the landing URL carries tracking parameters and the referrer is a classified tracker. A click on day 1 converting on day 9 looks direct. Different feature, different fix: set the cookie from your server, subject to the hosting condition above.

ESP redirect rewrites. Some ESPs hand the destination a different parameter set than the one in your email body, flattening custom parameters or rewriting UTMs to their own convention. That is configuration, not iOS.

In-app browser sandboxes. A link tapped in Instagram opens in a web view with its own cookie storage, so a returning visitor looks new. The click identifier arrived fine. Conversion APIs matching on hashed identifiers are the fix.

Diagnose first. Compare iOS Safari sessions that carry a click identifier against those that carry the same UTMs without one, and check where they came from. If the second group is small, you are about to spend a quarter mitigating a rounding error.

FAQ

What does Link Tracking Protection strip?

A community-documented list of click identifiers, most consistently gclid, fbclid and msclkid, plus dclid, twclid and mc_eid. Apple publishes no official list. UTM parameters are not stripped.

Are UTM parameters affected?

No. All six survive in every reported context, because they identify a campaign rather than a person. Campaign-level attribution in your analytics stays intact on stripped clicks.

Does it run in regular Safari?

Not by default. The default covers Mail, Messages and Private Browsing. A user who selects All Browsing in Settings, Safari, Advanced, Advanced Tracking and Fingerprinting Protection gets it in regular Safari too.

Did Safari 26 change that default?

Reports conflict, and no source on either side cites Apple documentation showing a change to the link-stripping setting. Apple’s press wording about fingerprinting protection has been widely read as describing this feature, which is the likeliest origin of the confusion. Treat the default as unchanged and verify against your own data.

Can users turn it off?

Yes, with the same setting, which also governs Mail and Messages. That is why device tests disagree between colleagues.

Is gclid stripped?

Yes, in the contexts where stripping runs. Mitigate with a Final URL Suffix so your UTMs arrive regardless.

What about gbraid, wbraid and li_fat_id?

Reporting has been inconsistent across releases. Test in your own environment rather than assuming either way. ttclid does not appear on current lists.

Does it affect Chrome on iOS or in-app browsers?

No. Third-party browsers have their own protections, and Chrome on iOS does not strip query parameters this way. In-app browsers are outside the feature entirely, though their cookie isolation causes attribution problems of its own.

How is this different from Intelligent Tracking Prevention?

Different features. Tracking Prevention is older, runs in regular Safari, and limits cookie lifetimes. Link Tracking Protection removes query parameters in specific contexts. Most “iOS broke attribution” reports turn out to be cookie expiry.

How do I tell whether it is affecting my campaigns?

Segment iOS Safari sessions with a click identifier against those with the same UTMs and none, and look at where they arrived from. Measure the volume before you build anything.

Start with the measurement, not the mitigation. Most teams discover the affected slice is smaller than the meeting suggested.