LinkCleanhttps://example.com/blog/launch?utm_source=newsletter&utm_medium=email&utm_campaign=spring
After LinkCleanhttps://example.com/blog/launch
utm_source
UTM campaign tags · Google Analytics (originally Urchin)
What utm_source actually does
utm_source is one of five campaign-tracking parameters Google Analytics watches for: utm_source, utm_medium, utm_campaign, utm_term, and utm_content. Of those, utm_source is the most common — it names the place a visitor was coming from when they clicked your link.
The receiving website's analytics tool sees the parameter, records it against the page view, and attributes that visit to the named source. None of that uses anything on the page itself; the tag is purely a back-channel from the link to the analytics tool.
Where the name comes from
UTM stands for Urchin Tracking Module. Urchin Software Corporation built one of the first commercial web-analytics products in San Diego in the late 1990s (founders Paul Muret and Jack Ancone). The “utm_” prefix is theirs.
Google acquired Urchin in April 2005 and relaunched the product as Google Analytics in November 2005. The “utm_” prefix stuck — by then so many links already carried utm_source / utm_medium / utm_campaign tags that renaming them would have broken billions of analytics reports overnight. It's been a de facto industry standard ever since.
What it leaks when you share the link
If someone sends you a link with utm_source=newsletter and you forward it on, every analytics tool downstream sees that the click originated from a newsletter — your forward is attributed to the original campaign, not to you. That's usually fine, but it also means the analytics audit log is broadcasting the campaign tag to everyone the link reaches.
It's not a personal identifier. utm_source doesn't carry your IP, your account, or anything that points back at you. It identifies the *campaign*, not the person. Still, sharing a link with utm tags reveals where you got it (a newsletter, an ad, a partner site), which is often more information than the sender intended you to pass along.
Why it's safe to remove
The page doesn't read utm_source. It's not used to load anything, not used to authenticate, not used to choose what to show you. Web servers route on the path; only analytics scripts look at utm_* parameters, and they do that *after* the page has already loaded.
Drop it, refresh, and you'll land on the same page. The only thing that changes is what shows up in someone else's analytics dashboard — and that's not your problem to solve.
How LinkClean removes it
utm_source is in LinkClean's default catalog, alongside the rest of the utm_* family (utm_medium, utm_campaign, utm_term, utm_content, utm_id, utm_source_platform, and a few newer variants). They're all stripped by default — no toggle, no per-site exception. They're vendor-specific enough that a benign collision is implausible: no legitimate URL uses utm_source for anything but analytics.
Paste a link in the app, hit Share → Clean URL, fire the Clean Clipboard intent from Shortcuts or the widget, or scan a QR code with utm tags — all of these run the same stripping pipeline, on-device.
Frequently asked
Does removing utm_source break the link?
No. The page itself never reads it. Web servers route on the URL path; utm_* parameters are read only by analytics scripts after the page has loaded. Drop them and the same page loads.
Why do publishers add utm_source in the first place?
To answer the question “where did our traffic come from?” without having to trust the HTTP Referer header (which browsers increasingly strip for privacy). It's a tag a publisher embeds in their own outbound links so they can recognize the same campaign across email, social, and partner sites.
Is utm_source personal data?
Not directly. It names a marketing channel, not a person. But shared links carry it forward — so passing one along reveals to every downstream tool that the click came from (say) a newsletter, which can quietly profile your sources.
Why does LinkClean strip utm_source but not “source”?
“source” is a common functional query key — it's used by many sites for non-tracking purposes (sort order, view mode, deep links into apps). utm_source is unambiguous: nothing legitimately uses it for anything but Google Analytics attribution. LinkClean's curation rule is “vendor-specific names get default-on, generic tokens stay default-off”.
Is this the same as fbclid or gclid?
Same idea (tracking parameters attached to a link), different vendor and different blast radius. utm_source is an analytics campaign tag — anonymous-ish, broadly used. fbclid and gclid are click identifiers Meta and Google Ads use to tie the click back to a specific ad impression and the cookie that saw it. LinkClean strips all three by default.
Clean it on iPhone, in one tap.
LinkClean strips this parameter — and 80+ others — from any link, from any app's share sheet. No account, on-device.
