Clean Tracking URLs — strip UTM, fbclid & co for sharing

What this tool does

This tool takes a URL and removes all known marketing tracking parameters. The cleaned URL appears immediately below the input, with a transparent diff view that shows what got removed and which system the marker came from. Optional bulk mode for many URLs at once, optional custom list for company-specific markers, optional fragment-tracker strip for edge cases like #_=_ on Facebook logins. Pure client, no server, no account, no tracking.

Where do tracking parameters come from?

Tracking parameters are a 20-year-old convention. In 2005, an analytics firm called Urchin introduced the Urchin Tracking Module — the five UTM parameters utm_source, utm_medium, utm_campaign, utm_term, and utm_content. Google acquired Urchin and folded UTM into Google Analytics. To this day the five-field convention is the de-facto industry standard for campaign attribution. Source: Wikipedia — UTM parameters.

Other platforms added their own markers:

• Facebook / Meta has automatically appended fbclid to every link clicked out of Facebook or Instagram since 2018. The token is a random click identifier Meta cross-references against the advertiser account server-side.
• Google Ads uses gclid for conversion tracking. iOS 14.5+ added gbraid (iOS apps) and wbraid (web variant) to work around Apple’s App Tracking Transparency restrictions.
• Microsoft / Bing Ads mirrors the pattern with msclkid, Yandex with yclid, TikTok with ttclid, LinkedIn with li_fat_id, Reddit with rdt_cid, Instagram with igshid.
• Email marketing: HubSpot uses _hsenc and _hsmi, Mailchimp uses mc_cid and mc_eid, Marketo uses mkt_tok. These tie the opened newsletter back to the clicking recipient.

Most of these parameters have no function for the page you land on. They are pure telemetry — a side-channel that runs in parallel with the content.

Which parameters does the tool detect?

A curated list of over 50 known markers. Here are the major ones grouped by source:

Platform	Parameters
Google Analytics	utm_source, utm_medium, utm_campaign, utm_term, utm_content, utm_id, _ga, _gid, _gl
Google Ads	gclid, gclsrc, dclid, gbraid, wbraid
Meta / Facebook	fbclid
Microsoft Ads	msclkid
Yandex	yclid
LinkedIn	li_fat_id, trk, trkCampaign
TikTok	ttclid
Reddit	rdt_cid
Instagram	igshid, igsh
X / Twitter Ads	twclid
HubSpot	_hsenc, _hsmi, __hsfp, __hssc, __hstc, hsCtaTracking, hsa_*
Mailchimp	mc_cid, mc_eid
Marketo	mkt_tok
Matomo / Piwik	mtm_*, pk_*, piwik_*
Vero	vero_id, vero_conv
Omeda	oly_anon_id, oly_enc_id
Publishers / Adobe-style	ICID, ito, ncid

Parameters ending in * are prefix patterns: utm_* matches anything starting with utm_, including very old conventions like utm_keyword or custom utm_partner.

Why bother removing tracking parameters?

Three reasons that matter most often in practice:

1. Privacy of the recipient. When you forward a link with ?utm_source=newsletter to a coworker, the destination website now thinks your coworker also subscribed to that newsletter — even though they never did. That distorts attribution and hands a third party data they have no claim on.

2. Clean appearance. https://kittokit.com/en/meter-to-feet?utm_source=foo&utm_medium=bar&utm_campaign=baz&fbclid=IwAR0xyz123&gclid=Cj0KCQjw_super_long_string is ugly. In Slack, WhatsApp, or X it looks suspicious and pushes the link towards the spam-y end of legibility.

3. Correct attribution. When your coworker then clicks the link from your Slack message with the newsletter utm_source still attached, Google Analytics credits the click to the newsletter again. Marketing teams use cleaners like this one as a mandatory step before every share to avoid this misattribution loop.

What about iOS 17 Link Tracking Protection?

Apple introduced a feature called Link Tracking Protection in iOS 17 in 2023. It automatically strips UTM parameters from URLs opened in Mail, received in iMessage, or visited in Safari Private Browsing. Source: Apple Developer — Link Tracking Protection.

That’s a genuine improvement — but the gap is large:

• Desktop browsers (Chrome, Firefox, Edge on macOS/Windows/Linux) do not auto-strip by default. Firefox has offered Query Stripping since 2022, but only in Private mode.
• Cross-app sharing on iOS (e.g. Safari → Slack via system share sheet) does not strip, because Slack receives the unmodified URL.
• WhatsApp Web, Telegram Web, X Web on desktop are not protected.
• AI workflows: ChatGPT, Claude, and Perplexity often return URLs with full tracking residue when citing sources.

For every one of those flows you need either a browser extension or a web tool. This is the web-tool variant.

What happens to parameters the tool does not recognize?

They stay in the URL. That’s deliberate: many query parameters are functional. ?id=42 selects an article, ?lang=de chooses the language, ?page=3 paginates a listing, ?q=test carries a search term. These never get falsely removed.

If your workflow uses company-specific markers — say ?clx_campaign from a private marketing system — you can add them to the Custom list under Options as a comma-separated list. They get applied on top of the curated list.

What this tool deliberately can’t do

Three things we intentionally don’t cover, so you don’t carry the wrong expectations:

Resolve short URLs. bit.ly/abc123 or t.co/xyz cannot be resolved from a browser without a server round-trip — CORS restrictions block that. We don’t follow short URLs. You’d open the short URL yourself, then copy the address-bar URL, then run it through this tool.

Strip affiliate tags. Amazon appends ?tag=..., eBay appends ?campid=.... These are technically trackers, but we don’t strip them by default because they are domain-specific and the tool would otherwise need to maintain a list of 200+ retailers. Add the parameter name to the Custom list if you want them gone.

Block web bugs and pixel tracking. If the shared page itself loads a tracking pixel (e.g. an invisible 1×1 image request to Google Analytics), we don’t block that. It happens server-side on the destination, not in the URL. Browser-level blockers like uBlock Origin are the right tool class for that job.

How it works under the hood

The code uses the native browser APIs URL and URLSearchParams, both standardized by RFC 3986. Every URL is parsed, every query parameter is checked against the curated blocklist (exact match or prefix match like utm_*), then either dropped or kept. Order of kept parameters is preserved, origin and path remain untouched.

The blocklist lives as a JSON file with a CC0 license in the source tree. Inspiration drawn from publicly documented marketing conventions — no derivation from proprietary lists. Reviewed quarterly.

URLs without a scheme (kittokit.com/foo?utm=x) are leniently prefixed with https:// before parsing. Duplicate parameter names (?utm_source=a&utm_source=b) are all removed, not just the first one.

What does the diff view actually buy you?

Other URL cleaners only show the cleaned URL and tell you nothing about what they removed. We show three columns per removed parameter: the name as it appeared in your URL, the source (Google Analytics, Meta, HubSpot, Mailchimp …), and the original value. That transparency carries practical value:

• Marketing and SEO teams verify that nothing functional disappears. A ?source=docs URL stays untouched because source is not in the blocklist. If it were ?utm_source=docs, it would be gone — and the diff makes the difference legible.
• Privacy auditors document which platforms leave tracking residue on a given site. When a non-profit’s Mailchimp newsletter drags five HubSpot markers along, that raises eyebrows.
• Developers debug marketing integrations. A UTM chain that travels through two redirects can be mutated along the way. With the diff you see what actually arrived.

The diff rows are sorted by query-string order, not alphabetically — preserving the original order so reading the input URL and the diff table doesn’t require swapping between two sorting logics.

When should you reach for bulk mode?

Bulk mode accepts newline-separated URLs and cleans each one independently. Sensible use cases:

• Newsletter QA: You have 50 links going into next week’s brand email — all sourced internally and still carrying UTM residue from earlier campaigns. Bulk strip in one second.
• Article research collection: You collected 30 research URLs in browser tabs and are exporting them to Notion or Obsidian. Pass them through the bulk cleaner first — the source list stays cleanly readable.
• Sitemap audit: External sitemap tools sometimes return URLs with crawler-internal marker parameters. Bulk-strip before importing into your own indexing tool.
• Affiliate separation: When an aggregator hands you 100 product URLs and you only want platform trackers removed (but want to keep the affiliate tag), use bulk mode without a custom list — affiliate tags stay, platform markers go.

Bulk has no hard limit, but the diff rendering becomes sluggish past ~500 URLs. For larger batches, slice the list into chunks or use the compact “Copy all” output that only places the cleaned URL list into the clipboard, skipping the per-URL diff rendering.

How does this relate to Privacy Sandbox and Topics API?

Google has been gradually phasing out third-party cookies in Chrome since 2024 through the Privacy Sandbox initiative — Topics API, Protected Audience API, and Attribution Reporting API as the core building blocks. That shifts the tracking model away from the URL layer towards server-side first-party data streams.

URL tracking parameters still matter, though. First: UTM and click IDs are cross-platform (Apple, Microsoft, Meta use them just as much as Google) — Privacy Sandbox only governs Chrome. Second: they are a “last-mile misattribution layer”. Even when the pixel-cookie model disappears, a marketer wants to know which newsletter sent a click — so the utm_source stays in the URL. Third: Sandbox APIs are browser-side; web servers have no access to them — server-side analytics stacks remain reliant on URL parameters.

Bottom line: even if the ad industry fully migrates to Privacy Sandbox by 2027, UTM stripping will stay relevant for at least another browser-generation cycle.

What are the most asked questions?

The most important answers are in the FAQ block above — they are emitted as structured JSON-LD (FAQPage) for search engines and answer engines.

Which related tools fit the same workflow?

Other tools in the kittokit ecosystem that fit the same context:

• URL Encoder Decoder — encode or decode special characters in URLs using RFC 3986 percent-encoding.
• Base64 Encoder — encode text to and from Base64 for data URIs, JWT payloads, and API headers.
• JWT Decoder — decode and inspect JWT tokens without sending them to any server.