The name suggests it blocks tracking links outright. It does not. Link tracking protection removes specific query string parameters, the kind ad networks attach to identify a person across sites, before a link is opened or shared in certain contexts. The link still works, the click still lands, and most campaign parameters survive untouched.
What gets stripped, and what does not
Both Apple and Mozilla maintain a list of known tracking parameters, things like
fbclid and other ad-platform click identifiers, and strip them from a URL before it
is shared or loaded in a protected context. Generic UTM parameters (utm_source,
utm_medium, utm_campaign) are not on either list by default. The
reasoning is technical, not sentimental: a click ID like fbclid is built to let one
company recognize the same visitor across unrelated sites, while a UTM tag only describes which
campaign sent the click and carries no identity value on its own. Browsers built these lists to
target the first behavior, not the second.
This is the point most explainers get wrong when they answer does Safari strip UTM: the honest answer is no, not by default, and not as a rule. What Safari strips is a curated list of cross-site identifiers, and UTM parameters generally are not on it.
Safari's link tracking protection: where it applies
Apple introduced link tracking protection with iOS 17 and macOS Sonoma. The detail that gets lost in most coverage is scope. It does not run on every page you visit in regular Safari. It applies in three specific places: Private Browsing tabs, the Messages app, and the Mail app, when a link is shared or when the linked page loads inside one of those contexts. Open the same link in a normal, non-private Safari tab and the URL arrives with its original parameters intact.
That distinction matters for anyone reading traffic logs. A campaign link opened from a text message on an iPhone may arrive stripped of its click ID. The same link opened from a normal Safari tab, or from an in-app browser inside Instagram or TikTok, will not be touched by this particular feature at all.
Firefox's link tracking protection
Firefox's version sits inside Enhanced Tracking Protection and is called query parameter stripping, live since Firefox 102. It runs automatically, on every page, inside Private Browsing windows. In normal browsing windows it only strips parameters when a user has set Enhanced Tracking Protection to Strict mode, which is not the default setting for most people. Mozilla's list draws on a maintained tracking-parameter database and, similarly to Apple's approach, targets known cross-site identifiers such as mailing-platform click IDs rather than generic UTM tags.
Browser tracking-parameter protections compared
| Browser feature | Runs in normal browsing by default | Runs in private/incognito windows | What it targets |
|---|---|---|---|
| Safari link tracking protection (iOS 17+, macOS Sonoma+) | No | Yes, plus Messages and Mail | Known cross-site click identifiers on Apple's list |
| Firefox Enhanced Tracking Protection, Strict mode | Only if the user enables Strict | Yes, always | Known tracking parameters on Mozilla's list |
| Firefox Enhanced Tracking Protection, Standard (default) | No | Yes, always | Same list, private windows only |
| Chrome | No built-in equivalent | No built-in equivalent | Not applicable |
Why in-app browsers matter more than either of these features
For anyone marketing through Instagram, TikTok or Facebook, the browser that actually opens a link-in-bio link most of the time is not Safari or Firefox at all. It is the platform's own in-app browser, a WebView embedded inside the app itself. That WebView does not inherit the device's system Safari settings, and it is not covered by Firefox's Enhanced Tracking Protection either, because it is not Firefox. In practice, most clicks on a link placed in an Instagram bio or a TikTok profile are never touched by link tracking protection, because the click never happens inside a context Apple's or Mozilla's feature is watching. The stripping mostly shows up when a link is shared peer to peer, through a text message or a DM, and then opened in a real browser rather than an in-app one.
That does not make link tracking protection irrelevant for social marketers. Email newsletters and text campaigns route straight through Mail and Messages, exactly the two contexts Apple's feature covers, so a link sent by email to an iPhone user is more exposed to this than a link placed in a bio.
What this means if you run campaigns
If your attribution depends entirely on a platform's own click ID, such as reading
fbclid out of a landing page URL to reconcile spend, a portion of privacy-conscious
traffic on Safari and Firefox will arrive with that ID already gone. You will still count the
visit, and it will still show up in basic click
tracking. You just will not be able to tie it back to the exact ad click through that
parameter alone. This is a real and growing share of traffic, not an edge case, since Private
Browsing and Messages links are common ways people open a link shared to them.
UTM-based tracking is the more durable choice precisely because it survives what click IDs do
not. A link built with a UTM builder keeps its
utm_source and utm_campaign values through link tracking protection in
every browser covered above, so campaign reporting built on UTMs tends to stay accurate even as
click-ID-based tracking degrades.
A concrete example of the mechanism
Say a retailer sends an email with a link that reads
https://shop.example.com/sale?utm_source=newsletter&utm_campaign=august&fbclid=abc123.
Opened on an iPhone directly inside the Mail app, Apple's link tracking protection strips
fbclid=abc123 before the request is even made, because Mail is one of the covered
contexts and fbclid is on the known-tracker list. Both UTM parameters survive
untouched, because neither is on that list. The retailer's server still receives
utm_source=newsletter and utm_campaign=august, so campaign-level
reporting is unaffected. What breaks is anything downstream that specifically expected
fbclid to be present, such as a Meta Pixel trying to match the click back to a
specific ad using that identifier.
The same link opened by tapping it inside a text message behaves the same way, since Messages is also a covered context. Opened by copying the URL and pasting it into a regular, non-private Safari tab, nothing is stripped at all, because regular browsing windows are outside the feature's scope entirely. The parameter survives or does not survive based on which app opened the link, not based on anything about the link itself.
How to keep your attribution working anyway
Two habits do most of the work here. Tag every outbound link with UTM parameters instead of leaning on a platform's auto-appended click ID as your only signal, and log the click server-side, at the moment someone hits your redirect, rather than waiting for a client-side script to fire on the destination page. A stripped parameter never even reaches a script that only runs after the strip has already happened. Raydar's link analytics work this way: every click is captured with UTM values, referrer and first-touch and last-touch cookies at the point the redirect is served, so the record exists whether or not the visitor's browser later strips a click ID from the address bar.
If you need to see what is actually inside a link someone sends you, run it through a link decoder before assuming what parameters it carries. And if the parameters themselves are unfamiliar, it is worth reading what UTM parameters are and how they differ from ad click IDs before you build your next campaign link.
None of this is a workaround for something browsers are actively trying to close. Cross-site click identifiers are being targeted deliberately, and that trend is not reversing. Campaign parameters that describe your own marketing, rather than identify a person across the web, were never really the target. That is the whole reason they are still standing.