UTM parameters, click IDs and redirect wrappers: how links track you and how to clean them

utm_source, utm_medium, utm_campaign, utm_term and utm_content come from Urchin, the analytics product Google bought in 2005; UTM stands for Urchin Tracking Module, and the naming convention outlived the software by two decades. Google Analytics 4 added utm_id, and Matomo, Piwik, HubSpot and Mailchimp each ship near-identical prefixes of their own: mtm_, pk_, hsa_, mc_.

They describe a campaign rather than a person: "this click came from the September newsletter, from the button at the top of the message". The analytics script on the destination page reads them out of the address bar; the destination server also records the full URL in its access log, parameters included.

Removing them changes nothing about the page you land on, because a competently built site ignores query parameters it does not recognise. What changes is what gets recorded about how you arrived — and what you pass on when you forward the link to someone else.

gclid is Google Ads auto-tagging; gbraid and wbraid are its privacy-era companions; dclid belongs to Display & Video 360. fbclid comes from Meta, msclkid from Microsoft Ads, ttclid from TikTok, twclid from X, li_fat_id from LinkedIn, igshid from an Instagram share, yclid and ysclid from Yandex.

These are opaque identifiers minted per click, and they are how a click is matched to a purchase weeks later. Email tools go further: Mailchimp's mc_cid names the campaign while mc_eid identifies the individual subscriber, so a newsletter link forwarded to a colleague still carries the identity of the person who forwarded it.

That is the practical argument for cleaning a link before you share it. A campaign label is impersonal; a click ID is not, and it keeps working for everyone who receives the link after you.

Corporate mail rewrites links before you ever see them. Microsoft Defender for Office 365 Safe Links turns every URL into https://<tenant>.safelinks.protection.outlook.com/?url=<encoded>&data=… so the destination can be re-checked at the moment you click. Google Docs rewrites external links to google.com/url?q=…, Facebook uses l.facebook.com/l.php?u=…, and LinkedIn, Reddit, VK and Tumblr all run wrappers of their own.

The real address is right there in a query parameter — url=, q=, u= or to= — URL-encoded. Decoding it is the entire job, and it needs no network request at all. ClipboardClean unwraps these automatically, up to three levels deep, because wrappers regularly contain other wrappers: a Safe Link around a Mailchimp redirect around the actual page.

Wrappers are not automatically malicious — Safe Links exists to catch phishing. But a wrapped link is unreadable to a human, it breaks when the wrapper expires or the tenant changes, and it logs the click. In a document meant to last, the unwrapped address is the one that will still work in three years.

bit.ly, t.co, lnkd.in, tinyurl and the rest keep the mapping on their own servers. The only way to learn where such a link goes is to ask them — which is exactly the request you were trying to avoid. A cleaner that runs entirely in your browser can flag a shortened link, but it cannot resolve one, and any tool that claims otherwise is making the request on your behalf.

Some shorteners offer a preview instead of a redirect: adding a plus sign to the end of a Bitly link opens an information page rather than sending you onward. That still contacts Bitly, but it does not count as a click-through to the destination and it shows you where you would have landed.

The durable habit is to keep shorteners out of documents that need to last. A shortener is a redirect you do not control, pointing at a destination that can be changed after the link has been sent — and that stops working entirely when the service shuts down, as goo.gl did.

Deleting utm_ and its relatives, gclid, gbraid, fbclid, msclkid, mc_cid, mc_eid, mkt_tok, yclid and the rest of the click-ID family is safe on practically every site: those parameters are read by analytics, not by the code that decides which page to render.

Be careful with the handful that do double duty. ref and source are analytics on most sites and functional on a few; si on a YouTube share link is a share identifier; spm on Alibaba properties is tracking, but some pages read it for layout. This tool lists every parameter it removes under the options row, and keeps a "Keep as they are" mode for the moment a cleaned link misbehaves.

Leave alone anything that is obviously state: session identifiers, page numbers, search queries, language switches and everything after the # in a single-page application. Cleaning only ever removes query parameters — it never rewrites the path — so it cannot turn a working link into a missing page on its own.