URL Cleanerstrip the tracking, keep the link working.
Paste a link and see exactly what is riding along: who put each parameter there and what it was measuring. Remove them, or keep the ones you want. Nothing leaves your browser.
Nothing is sent anywhere. The cleaning happens in this tab, which is the only way a privacy tool can honestly work.
Paste a link above to see what it is carrying.
Options
Pulls the real destination out of a Google, Facebook or Outlook wrapper. On by default because the wrapper is the tracker.
Safe in theory, domains are case insensitive. Off by default because it changes a link you may be comparing against a log line.
:443 on https and :80 on http mean nothing. Rare enough on real links that it is not worth changing them silently.
Some sites treat ?print or ?debug as a flag with no value, so dropping it changes what the page does.
Useful for deduplicating a list. Risky on any site that reads parameters positionally, and it changes signed URLs.
The part after # never reaches the server, so it is not tracking. On single page apps it is the whole route.
Your own rules
Add a parameter name your stack adds and this list does not know about. Saved in this browser only.
Clean the page you are on
Drag this to your bookmarks bar. On any page, click it and the tracking parameters come off the address bar in place, using the same global list as the tool above. It rewrites the URL locally and contacts nothing.
Clean this URLEverything above runs in your browser, there is no network call in this tool. 178 parameter rules, last checked against the source catalogues on 2026-09-01.
What does a URL cleaner actually remove?
A link is made of parts that do different jobs. A cleaner has to know which part it is looking at, because two of them look identical in the address bar and only one of them is safe to touch.
The path is untouchable
Everything before the question mark identifies the page. Change it and you get a different page, or a 404. A cleaner never rewrites it, and never changes its capitalisation either, because paths are case sensitive on most servers even though domains are not.
The query is where it lives
After the question mark sit name and value pairs. Some run the page: a product variant, a page number, a search term, a session token. Others only tell an analytics tool where you came from. They sit side by side and nothing in the syntax separates them.
The fragment usually stays
The part after the hash never reaches the server, so it cannot be a tracking beacon in the usual sense. On a single page app it is often the entire route. This tool keeps it unless you ask otherwise.
The difference is knowledge, not syntax
There is no rule you can apply to a parameter name to know whether the site needs it. The only honest way to tell is a catalogue of known trackers, which is why the list behind this tool matters more than the code around it.
Why is fbclid in your link in the first place?
Nobody types these. They get attached along the way, by four different mechanisms that have nothing to do with each other.
You tagged it yourself
utm_source, utm_medium and utm_campaign are added by whoever built the link, usually to make a campaign show up correctly in analytics. They are the polite kind: documented, standard, and completely useless to anyone but the person who set them.
The ad platform stamped it on the click
fbclid and gclid are added by Meta and Google at the moment of the click, not by the advertiser. That is why they appear on links you never tagged, and why they survive being copied and pasted into a group chat weeks later.
The email tool rewrote the link
Mailchimp, HubSpot and the rest replace your link with their own, then append an identifier tied to the individual subscriber. Forward that email and you forward a link that says who opened it.
The share button added its own
Copying a link out of the Instagram, TikTok or X apps attaches a share identifier. It is what lets the platform reconstruct who shared what to whom, which is the part most people are surprised by.
Which parameters are safe to remove everywhere?
This is where URL cleaners get it wrong, and where this one is deliberately careful. There are two kinds of rule, and treating them as one kind is what breaks links.
Global rules, safe on any domain
A small set of parameters exists only to attribute a click and is never read by the page itself. utm_source and its family, fbclid, gclid, msclkid, ttclid, mc_eid. Removing them cannot change what you see, on any site, ever. This tool applies 95 of them everywhere.
Per domain rules, safe on one site
Others are only tracking on the site that owns them, and mean something completely different elsewhere. On YouTube, si is a share identifier and v is the video: remove the wrong one and the link stops working. 83 rules here apply to one domain and nowhere else.
Some parameters are protected outright
On Amazon, th and psc select the product variant. On YouTube, v, t and list decide what plays and where it starts. These are marked as protected, so no rule, including one you add yourself, can strip them.
Anything ambiguous stays
Parameters like s, t and source are tracking on some sites and functional on others. There is no safe global answer, so they are left alone unless a per domain rule covers them. A cleaner that guesses here is a cleaner that quietly breaks things.
The parameter list is not written from memory. It is built from the two catalogues that maintain this for a living, the ClearURLs rules and the AdGuard URL tracking filter, with the source and the date recorded next to every group in the code. When they disagree, the narrower rule wins.
What breaks when a cleaner is too aggressive?
Every failure below comes from the same instinct: assuming a parameter is decoration because it looks like decoration. These are the cases this tool is built around.
The removed parameter was the product
Strip the variant selector from a shop link and it opens the wrong colour. Strip the page number and it opens page one. The link still loads, which is worse than an error, because nobody notices until a customer does.
Cleaning twice gave a different answer
Run a cleaner over its own output and you should get the same string back, byte for byte. If you do not, the tool is unstable and you cannot trust it in a pipeline. That property is covered by a test here, not assumed.
The token was mistaken for tracking
Password resets, signed download links and preview URLs carry a parameter that expires. It looks exactly like a tracking identifier. Nothing in this catalogue removes an unrecognised parameter, precisely because of these.
The link was double encoded
A redirect wrapper often carries the real destination encoded inside itself, sometimes twice. Decoding once leaves half a URL, decoding forever is a way to hang the browser. This one decodes up to five times and then stops.
The reverse job has its own tool: if you are building campaign links rather than stripping them, the UTM link generator adds the same parameters this page removes, and adds them in the form GA4 reads correctly.
If the link is going out on social, check what the card will look like with the link preview checker.
And if you were handed a QR code rather than a link, see where it points first with the QR code resolver.
How do you clean a whole export at once?
One link at a time is fine for a group chat. A backlink audit, a sitemap or a spreadsheet of affiliate links is a different job, so the second tab does that one.
Paste the column
One link per line, as many as you like. It processes in chunks with a progress bar rather than freezing the tab, and lines that are not valid links are flagged in place rather than stopping the run.
Read the removed count
The table shows each original next to its cleaned version and how many parameters came off. A row with a surprisingly high count is usually an email link, which is worth looking at before you publish it anywhere.
Export or copy
Download the whole table as a CSV, or copy just the clean column straight back into the spreadsheet you took it from. The CSV is built in the browser like everything else here.
Add the rules your stack invents
Most companies bolt on a parameter of their own that no public catalogue knows about. Add it once under your own rules and it is stripped from every link after that, on this device.
One last thing worth knowing: cleaning a link does not change how it is judged. What people see is the domain in front of the slash, and a link on a shared shortener inherits whatever reputation everyone else on it earned. That is the argument for a branded domain of your own, which is a different problem from tracking parameters and a more permanent one.
URL cleaner questions
Still have questions?
OnlineReal humans, usually replying in a few minutes.
No. The cleaning runs entirely in this browser tab: the rules are shipped as part of the page and the parsing happens in JavaScript on your device. There is no fetch call in this tool and none in the modules it uses. A URL cleaner that uploaded your links would be collecting the browsing history it claims to protect, which is why the whole thing is built to work offline.
Go further with LinkScale
Clean links are the easy half. Knowing what happened after the click is the other one.
Stripping the tracking out of someone else’s link takes a second. Getting reliable data out of your own, on a domain you control, is what LinkScale is for.
Free 14-day trial on every plan