Do Firefox and Brave Strip UTM Parameters? What Survives

Short answer: Firefox does strip query parameters, but the release list Mozilla documents is mostly ad and email identifiers such as fbclid and mkt_tok. Your utm_source and utm_campaign tags aren't on it. If campaign data is vanishing, the cause is more often a blocked script, denied consent or a destination that drops the query string.

That corrects the claim this post used to open with, and it matters, because if you blame the wrong mechanism you fix the wrong thing. Here is what each browser documents, what to test yourself, and where the loss really sits. For the tags themselves, see UTM parameters explained. For storage and cookie limits, see click attribution after Safari ITP.

What Each Browser Documents

Everything below is from vendor pages, accessed 2026-10-24. Where a page didn't say, I say so instead of guessing.

Firefox. Mozilla's query stripping documentation says it's enabled in release in Enhanced Tracking Protection Strict, with an initial list of parameters: mc_eid, oly_anon_id, oly_enc_id, __s, vero_id, _hsenc, mkt_tok and fbclid. Private Browsing windows aren't covered by default; Mozilla says it's considering that and a preference exists. Nightly uses an extended list held in Remote Settings, which that page doesn't reproduce. No utm_ parameter appears in the release list.

Safari. WebKit describes Link Tracking Protection as part of Private Browsing, removing a subset of query parameters that identify cross-site tracking, before navigation. The same protections apply to regular browsing when a user enables the advanced tracking and fingerprinting setting for all browsing. WebKit says attribution parameters such as campaign are allowed to pass through. It doesn't name utm_ tags either way.

Brave. Brave's query-string filter has simple, conditional and scoped rules. The one parameter its wiki names is mkt_tok, removed except on unsubscribe URLs. The full list lives in brave-core, and I couldn't confirm from the pages I read whether any utm_ tag is on it. I also couldn't confirm Brave's behaviour toward GA4 from vendor documentation, so I'm not stating one.

So Where Does the UTM Data Go?

Three causes explain most of it, and none is "the browser deleted my tags".

1. The destination host drops the query string. A trailing-slash redirect or a hosting rule can discard everything after the question mark. Why UTM parameters don't show in GA4 walks this decision tree.
2. The analytics script doesn't run. Tracking protection and extensions block known analytics domains. The tags are in the URL; nothing reads them.
3. Consent was denied. Same effect, different reason. The clicks-versus-sessions gap in Short-Link Clicks vs GA4 Sessions is mostly this plus bots and merged sessions.

The click identifiers are the real casualty. fbclid is on Firefox's strip list, so Meta-bound click IDs can disappear in Strict mode even when your UTMs survive. That matters if you rely on click IDs for ad-platform matching. Click IDs explained covers which platforms use which.

Test It on Your Own Links

Don't trust a blog post, including this one, for a list that changes between versions.

It takes five minutes.

1. Make a short link to a page you control with ?utm_source=test&utm_medium=test&utm_campaign=check&fbclid=abc&mkt_tok=xyz on the destination.
2. Open it in Firefox with Strict protection, in Safari Private Browsing, in Brave, and in Chrome.
3. Read the final address bar in each. Whatever is missing is what that browser strips on that day.
4. Repeat after a major browser update, since lists grow.

Why the Wrong Story Spreads

"Browsers strip UTMs" is a tidy explanation, so it gets repeated. It's also a hard one to disprove from inside a GA4 report, because a missing campaign looks the same whatever removed it. A session filed under direct or unassigned could mean a stripped tag, a redirect that dropped the query string, or an app that never sent a referrer.

The cases differ in what you can fix. A host that drops the query string is a one-line server change. A blocked script is outside your control, and so is a denied consent prompt. Stripped click IDs only matter if you built reporting on them. Lumping the four together as "privacy browsers" sends you to the wrong place, which is why the test above is worth more than any percentage I could quote. I'm deliberately not giving one: the figures that circulate for privacy-browser share come from vendor surveys with different definitions, and your audience isn't the average one.

Reading Your Own Browser Split

Once you've run the test, put numbers on your own traffic. In GA4, break sessions by browser for one campaign and compare with the short-link click count for that campaign over the same dates.

• Your Chrome ratio of sessions to clicks is the baseline. It carries the usual scanner, bot and abandonment losses.
• A markedly lower ratio in Firefox or Safari points at script blocking or consent, since UTM stripping alone wouldn't remove the session, only its campaign label.
• A normal ratio with a high share of direct or unassigned in one browser points at tags or click IDs being lost, not at the tag failing to load.

That second pattern is the one worth chasing, and it's the only one where a browser feature actually removed something you sent. Everything else is a visibility problem you manage with a baseline, not a bug you fix. If your clicks and sessions already differ for reasons unrelated to browsers, resolve those first with the afternoon routine in the clicks versus sessions post linked above.

Record the Click Before the Browser Touches It

Whatever each browser does, it does it at the landing page. A short link resolves at the redirect and logs the click first, so what the browser strips or blocks afterwards can't change that the click happened.

In Elido the edge redirect writes the click event (link, time, country and device) as the response is sent, and known crawlers and preview bots aren't counted. Click events can then be forwarded to GA4 and other tools, which GA4 server-side tracking via redirects covers.

The limit is real: this recovers the acquisition count, meaning that a click happened and which link it was. It doesn't recover the on-page session, events or conversion if the tag was blocked. For revenue, attribute orders to a link server-side, as in tracking UTM campaigns end to end.

What to Do

• Keep your UTMs. The documented lists don't target them.
• Treat click IDs like fbclid as lossy, and don't build reporting that needs them.
• Run the five-minute test above after browser updates.
• Wrap campaign links in a tagged short link so the click is counted at the redirect. Elido's link analytics shows those counts per campaign.
• Reconcile clicks against GA4 sessions per campaign and per browser, and track the ratio over time.

Read the Cornerstone Series

This sits in the engineering cluster. Start with track UTM campaigns end to end for the full pipeline.

Related on the Blog

• Click attribution after Safari ITP
• UTM parameters explained: the complete guide
• Short-link clicks vs GA4 sessions
• Click ID explained: gclid, fbclid, ttclid and msclkid
• Cookieless attribution, explained
• UTM parameters not showing in GA4: causes and fixes