chrome-utm-stripper: the tracking token stripper that Chrome retired

What it does, and why doing it before the request matters

This is a Chrome and Firefox browser extension that strips Google Analytics parameters, and various other click tracking tokens, from URL query strings. The implementation detail that defines the project is this: it is done before the web request is made, and it results in both more private browsing as well as more aesthetically pleasing URLs.

That ordering is the whole design. Most tracking protection works by blocking the request to the analytics endpoint after the page has already loaded, which stops the ping but leaves the identifier in the URL you visited, in your history, and in whatever the site server saw. Removing the parameter before the request means the site never receives it in the first place. It also means the URL in your address bar and the URL you paste to someone else is the clean one.

The parameter list is long and specific, which is what makes the extension useful rather than merely present. Facebook contributes fbclid. Google contributes gclid plus a long set of utm variants, including the less common utm_cid, utm_internal, utm_klaviyo_id, utm_reader, utm_referrer, utm_name, utm_social and utm_social-type. Then there is a section for other tools: ActiveCampaign's vgo_ee, HubSpot's _hsenc and _hsmi, Instagram's igshid, Klaviyo's utm_klaviyo_id, Mailchimp's mc_cid and mc_eid, Marketo's mkt_tok, Microsoft's cvid and oicd, Olytics identifiers, Wicked Reports' wickedid, Yahoo's soc_src and soc_trk, and Yandex's _openstat and yclid. There is also a catch-all for ICID, rb_clickid, and stm_ variants of the utm_ parameters.

Grouping the list by vendor is what tells you this was built by someone who was tired of specific tracking links, and the per-vendor grouping is also how you would extend it.

The permissions, and the API they imply

The extension requests four permissions, and each one is there for a reason that the guide explains.

The first is webRequest, to use the chrome.webRequest API. The second is webRequestBlocking, to use chrome.webRequest in a blocking fashion. Then there are two host permissions, http://*/*?* to filter http URLs and https://*/*?* to filter https URLs.

The blocking permission is the interesting one. It is what allows the extension to stop a request and rewrite its URL before it goes out, rather than merely observing requests as they happen. Chrome's own documentation on declaring permissions is linked, and the query string wildcard in the host patterns is a deliberate restriction: the permission only covers URLs that have a query string, since a URL without one has nothing to strip.

That pair of host permissions is broad, and it is worth being clear-eyed about what it means. The extension sees every http and https URL your browser requests that carries a query string. It is not reading page content and not reading cookies, and the whole implementation is a small background script, but the permission surface is wide because the operation has to happen before any network request leaves.

The implementation is correspondingly tiny. The repository top level holds background.js, manifest.json, the two icon files, the README, the LICENSE, a .eslintrc, a Makefile and a store/ directory. A single background script, no content scripts, no popup, no options page, no bundled libraries. The Makefile makes the packaging trivial:

zip store.zip LICENSE README.md background.js icon-*.png manifest.json

That is the entire build. A store zip is a zip of the extension files, and the Makefile target produces exactly that from the five files that matter. There is no build step, no transpiler, and no dependency tree, which is also why the extension has not changed much in years.

The Chrome removal, and the author's reasoning

The important section is the warning at the top of the guide, and it is the reason this project is worth writing about now.

This extension is no longer available in the Chrome Web Store. It was removed, along with all other Manifest V2-based extensions, on August 31, 2026. The removal follows the Manifest V2 deprecation timeline published in the Chrome developer documentation.

The author's response is the more informative part. He says he is not motivated to rewrite this extension from Manifest V2 to V3. The work appears to be non-trivial for this kind of extension, and after that amount of effort, it will not work any better than the current version.

That reasoning is a real signal about the state of the extension ecosystem. Manifest V2 gave extensions a blocking webRequest API, which is what makes it possible to cancel a request and send a modified one. Manifest V3 replaced that with a declarative rules model plus a service worker, and the specific capability this extension depends on was the thing under discussion.

The author judged that the rewrite would be significant work for no behavioural gain, and declined. The result is that the extension survives in the Firefox Add-ons and the Edge Add-ons store, and is gone from Chrome, and its author is candid about why rather than quietly letting it rot.

The last push to the repository was on 2026-09-01, and the last tagged release is 2.12 from 2024-12-19, before 2.11 in October 2024 and 2.10 in November 2023. So the code is still being touched while the Chrome distribution is gone, which tells you the maintenance is about keeping the Firefox and Edge builds working rather than about new features.

The alternatives, and the one that is already built into your browser

The alternatives section is unusually thorough, and one entry in it changes the shape of the decision.

uBlock Origin includes a removeparam feature that supports fine-grained matching and removal of query string parameters, and the AdGuard URL Tracking Protection list provides well-maintained coverage for a large number of domains and query string tokens. So the blocking-oriented tool most privacy-minded people already run can do the same job, with a maintained filter list behind it rather than a hand-maintained one.

The entry that changes the decision is Firefox. Firefox includes built-in support for query parameter stripping. The default set of removed query params is limited, but you can configure your own via the privacy.query_stripping.strip_list pref. The guide links the Firefox source documentation for the feature and the records that define the default set.

So on Firefox there is no reason to install this extension at all if you want the standard handful of parameters stripped, and a reason to install it only if you want the full vendor list applied everywhere. The pref is a plain text list, so moving a parameter from the extension to the pref is a one-line change.

There is also StopTheMadness for Apple platforms, covering Safari on iOS and iPadOS and Safari, Firefox, Chrome and Chromium on macOS, which lets you customise the list of query tracking parameters automatically removed from URLs, including domain-specific removal. The domain-specific part is a capability the other options lack, and it is worth checking whether you actually need it.

Finally there are two more extensions listed, ClearURLs and URL Tracking Stripper. The ClearURLs name is a good hint about the other approach in this space, since that project works by adding rules to the URL before it is requested rather than by removing parameters afterwards, which is a different mechanism with different coverage.

What the project is worth now, and how to pick between the options

The honest summary is that this is a small, well-scoped, MIT licensed project that solves one problem exactly, and whose distribution on the largest of the three browsers is gone for a reason outside the author's control.

What it still offers is the complete vendor-by-vendor parameter list, a blocking implementation that removes the token before the request rather than after it, and a codebase small enough to read in a sitting. If you want to understand how URL rewriting in an extension works, or you want to fork it for your own list, the source is a single background script with no dependencies.

What it no longer offers is Chrome, which is a large fraction of the browser market and, for a security and privacy tool, the one where you would most want to run it. The alternatives section exists because the author knows the extension has a finite life in its current form, and the list it points to includes two options that are maintained, widely deployed and do the same job.

So the decision is a comparison of three mechanisms rather than a search for one tool. A blocking rewrite in an extension, which is this project, removes the parameter before the site sees it but needs a maintained list and now cannot run in Chrome. A declarative filter in a content blocker, which is uBlock Origin and the AdGuard list, is maintained by a larger community and ships to Chrome, at the cost of being a different kind of tool that does far more than this. A browser feature, which is Firefox's query stripping, is built in, needs no extension, and gives you a configurable list but only a limited default set.

If you are on Chrome and you want this behaviour, uBlock Origin with the AdGuard list is the closest match to what this extension did, and it is maintained. If you are on Firefox, the built-in pref is worth trying before you install anything.

Editorial conclusion

Adopt the Firefox or Edge build of this extension if you want tracking parameters removed before the request is made rather than after, and if you are willing to maintain the list yourself. Do not expect it to appear in Chrome, because the extension was removed from the Chrome Web Store on 2026-08-31 and the author has stated he is not motivated to rewrite it for Manifest V3. Before you settle on one of the alternatives, check whether Firefox's own query stripping pref or uBlock Origin's removeparam feature already covers the parameters you actually see, since both are maintained by people who still ship to Chrome.

Frequently asked questions

Official sources

1. Issues
2. jparise/chrome-utm-stripper on GitHub
3. License: MIT
4. README
5. Releases