How Strip Tracking Params is built
Strip Tracking Params takes one or more pasted URLs and returns them with tracking parameters — utm_source, fbclid, gclid, and dozens like them — removed, entirely in the browser. This post covers why the removal list is hand-authored rather than borrowed, and a genuine cross-browser disagreement about what a “valid URL” even is that surfaced while testing the error path.
Tech used
URL and URLSearchParams, nothing else
Stripping tracking parameters doesn’t need a library: the browser’s own URL constructor parses a URL into its parts, and URLSearchParams gives structured access to the query string — delete the tracking keys, reassemble, done. There’s no dependency here to license-check or keep updated.
A hand-authored parameter list, not a borrowed one
The well-known open-source project for this exact job, ClearURLs, ships its removal rules as a rules.json data file — and it’s GPL-3 licensed. Copying that file wholesale into an MIT-licensed tool would tie this tool’s data to a copyleft license it doesn’t otherwise carry, so the list here is authored independently from public documentation of what each tracking parameter is for (utm_*, fbclid, gclid, gclsrc, msclkid, igshid, _ga, ttclid, and more), kept in one small, easily-extended file. It’s a smaller list than ClearURLs’ — this tool optimizes for the tracking parameters that actually show up on pasted URLs in practice, not for exhaustive coverage of every ad platform’s scheme.
A URL that one browser accepts and three reject
The tool’s “invalid line” test needed a URL that’s reliably invalid — reliably, it turned out, was the hard part. The first fixture used was a string with embedded spaces and no scheme. Firefox, WebKit, and Node’s own URL parser all rejected it, as expected. Chromium didn’t: instead of throwing, it silently percent-encoded the spaces into the hostname and returned a “successfully parsed” URL — a real, observable difference in how strictly each engine’s URL implementation validates a host, not a bug in this tool’s code. The fixture that ended up in the test suite uses a | character in the host position instead, a code point every one of the four engines rejects identically, which is what “shows a per-line error without crashing the batch” actually needed to test reliably.
A URL without a scheme still works
Pasting example.com/page?utm_source=x (no https://) is common enough that the tool retries with https:// prepended if the bare string doesn’t parse on its own, rather than requiring a fully-qualified URL as the only accepted input.
Implementation & operational notes
Nothing is persisted. The pasted URLs aren’t written to localStorage, which is a small extra step beyond “don’t send it to a server” — a reload clears the input completely, so there’s nothing sitting in the browser’s storage to find later either.
The output never puts the URLs in this tool’s own address bar. A URL-stripping tool putting the URLs you paste into its own page URL would be a fairly on-the-nose privacy failure, so it’s covered by a dedicated e2e check rather than left to the general “no input in a shared link” rule this catalog otherwise runs for every tool.
A bad line doesn’t take down the batch. Each pasted line is parsed independently — a per-line try/catch means one malformed URL produces a per-line error message next to the clean output for every other line, not a single top-level failure.