Browsers strip your click IDs and leave your UTMs

Most teams treat a missing click ID as a tagging fault: auto-tagging switched off, a redirect that drops the query string, a landing page that rewrites the URL. Some of those clicks lost the ID on purpose. Three browsers remove click IDs from the URL as the visitor arrives, and none of them touches your UTM parameters.

We ran one ad-click URL through the two strip lists that are published. Firefox in Strict mode and Brave both remove Google’s, Meta’s and Microsoft’s click IDs. Neither removes LinkedIn’s, Snapchat’s, Reddit’s or Pinterest’s. All three UTMs survive in both. The visit still shows up in analytics with its campaign. The ad platform can’t match it to a click.

When each browser strips, and what it reads

Read from each vendor’s own source on 6 November 2026. Every cell is in facts above with its source.

Browser	When it strips	Which list	What a script on the landing page can read
Firefox	Only in Strict Enhanced Tracking Protection, in normal and private windows. Off in the default Standard mode	Published: 22 parameters in Mozilla Remote Settings	Whatever survived the strip
Brave	By default, on every cross-site GET navigation while Shields are up. Same-site links are exempt	Published: 65 parameters for every site, plus rules for Instagram, X and YouTube	Whatever survived the strip
Safari	Private Browsing, or all browsing if the user turns on Advanced Tracking and Fingerprinting Protection	Not published. WebKit’s post uses known_tracking_param as its example	Third-party scripts get no query string at all, kept parameters included

What this does not cover: Chrome and Edge, which we found no published navigation strip list for, and browser extensions, which carry their own lists. The worked example below applies each browser’s published rules; it is not a capture from a live browser session.

One URL, two strip lists

The URL a visitor might land on if every platform tagged the same click. The 11 click IDs come from 9 platforms. Google’s _gl is the GA4 cross-domain linker, not an ad ID, and is there because Brave lists it.

https://shop.example/landing?utm_source=google&utm_medium=cpc&utm_campaign=bf26
  &gclid=…&gbraid=…&wbraid=…&srsltid=…&msclkid=…&fbclid=…&ttclid=…
  &li_fat_id=…&ScCid=…&rdt_cid=…&epik=…&_gl=…

A Python script checked each parameter against both lists as downloaded on 6 November.

Parameter	Whose	Firefox (Strict)	Brave
gclid	Google Ads	stripped	stripped
gbraid	Google Ads (iOS app)	stripped	kept
wbraid	Google Ads (iOS web)	stripped	stripped
srsltid	Google Merchant Center free listings	kept	stripped
msclkid	Microsoft Advertising	stripped	stripped
fbclid	Meta	stripped	stripped
ttclid	TikTok	kept	stripped
li_fat_id	LinkedIn	kept	kept
ScCid	Snapchat	kept	kept
rdt_cid	Reddit	kept	kept
epik	Pinterest	kept	kept
_gl	Google Analytics cross-domain linker	kept	stripped
utm_source, utm_medium, utm_campaign	UTM	kept	kept

Firefox removes 5 of the 11 click IDs and Brave removes 6. They agree on 4: Google’s gclid and wbraid, Meta’s and Microsoft’s. Four survive both lists: LinkedIn’s, Snapchat’s, Reddit’s and Pinterest’s.

Three details in that table are worth a second look.

• Firefox’s strip list has not grown since March 2023. The last record that added parameters was modified on 13 March 2023. ttclid is not on it, though Brave strips it.
• Brave keeps gbraid and strips wbraid. Google’s Data Manager API treats both as Google Ads click IDs, next to gclid. The two lists disagree on one of Google’s three.
• Brave strips _gl. That is not an ad click ID. It is how GA4 carries one session from your site to a checkout on another domain. In Brave, a visitor who moves from shop.example to pay.example becomes two users and two sessions, and the checkout session starts without the campaign that brought the visitor. Same-site moves, like www.shop.example to checkout.shop.example, are exempt.

Two ways to lose the ID, and only one you can fix

The browsers do two different things, and the difference decides what you can recover.

Firefox and Brave rewrite the URL before the request leaves the browser. Brave’s filter acts on the request itself, and Firefox strips on redirects too, so a click that passes through the platform’s redirect loses the ID on the way. Your server never receives the parameter. Server-side tagging does not help, because the value never reached a server. Meta’s advice to read fbclid from the HTTP request is sound, and in these two browsers there is nothing to read.

Safari does that, and then it hides the rest from scripts. After a cross-site navigation in Private Browsing, a third-party script that reads location.search gets an empty query string. Google’s own setup page loads the Google tag from www.googletagmanager.com, another site’s domain. So in Safari Private Browsing the UTMs Safari kept are in the URL, and a tag installed that way may still not see them. Your server does see them, because they were sent with the request. Safari 26 added a related rule for all known fingerprinting scripts: they cannot read query parameters or the referrer.

That gives the rule. A parameter removed before the request is gone for everyone. A parameter hidden from scripts is still in your server’s access log and in anything your own first-party code reads from the request.

What it costs

For Google, the cost is stated plainly: Google calls the GCLID required for Google Ads website conversion tracking. A conversion from a stripped click can still reach Google Ads through other identifiers. Google’s Data Manager API accepts a hashed email, the landing page IP address or a lead ID in place of a click ID. Without one of those it is a signal loss the platform reports as fewer conversions, or fills with a model.

Analytics doesn’t see the same gap. The UTMs arrive, so the session keeps its campaign, and GA4 and the ad platform disagree about a click that both of them saw. Read the gap between them as partly tracking prevention, not only as attribution-model difference.

What to do differently

1. Capture the query string on your server, on the first request. Store every click ID and UTM that arrives, against the visitor, before any script runs. This recovers what Safari hides from scripts. It cannot recover what Firefox and Brave removed, so count those separately: landings with a utm_medium of cpc and no click ID, split by browser.
2. Send a second match key with every conversion. A hashed email or phone through Google’s Data Manager API, Meta’s Conversions API or Microsoft’s equivalent is the only way a stripped click still matches. On LinkedIn, Snapchat, Reddit and Pinterest the click ID alone still survives Firefox and Brave.
3. Keep checkout on the same site, or stop relying on _gl. A checkout on a subdomain is same-site and Brave leaves the linker alone. A checkout on a payment provider’s domain loses it, and with it the campaign on the session that converts.

Option two is what most platforms already push you towards. When the click ID is gone and no hashed email matches, the platform falls back to a model of the conversions it could not see. How much traffic does an account need before that model even switches on?