dont-track-me-google: undoing Google search link tracking in the browser

Google rewrites the link on click, and the extension rewrites it back

The problem is stated in one line: at the Google Search engine, search results are converted to an ugly link upon click, and this link enables tracking for Google.

The example in the README shows what that means. Searching for Google and clicking the result does not take you to http://www.google.com/, it takes you to a long encrypted.google.com URL carrying the original address as an encoded url parameter, plus a set of session and tracking identifiers.

That redirect is not cosmetic. It is the point at which Google records that you clicked a particular result from a particular search, and it is why the address you see in the address bar is not the address of the site you visited. The extension's job is to remove the link-conversion and tracking feature, and the README states two consequences: this speeds up loading search results and allows you to right-click or tap to copy the link URL.

The second consequence is the one people notice. A Google search result link cannot normally be copied, because copying it copies the redirect rather than the destination. Once the conversion is removed, the underlying href is the real URL, and copy, middle-click and open in a new tab all behave the way they do everywhere else on the web.

The mechanism is deliberately narrow. This is not a content blocker, not a tracker that inspects network traffic and not a search alternative. It runs on the Google results page and rewrites the anchor targets. That narrowness is the reason it can be trusted to be lightweight, and also the reason it does nothing about tracking that happens elsewhere.

The primary language is JavaScript, the licence is MIT, the default branch is master, and the repository has no GitHub releases. The last push was on 2026-09-01.

The goto URLs need a round trip to Google, and only the extension can do it

Since August 2026, Google hides URLs behind google.com/goto?url=..., tracked as issue 67 in the repository.

This is a different problem from the old redirect. The old encrypted.google.com URL at least contained the destination in a query parameter that could be decoded locally. A goto URL does not, so there is nothing to decode. To show the real URL, something has to ask Google what it points at.

That is what the extension does. To reveal the real URL earlier, the extension may send a request to Google to retrieve the URL behind a goto URL, when you start interacting with a goto link in the search result. And you can opt out of this feature at the options page.

Three things about that behaviour deserve attention.

First, the request happens on interaction, not on page load, so the cost is paid only for a link you actually touch. Second, it is opt-out, which means the default is to send the request. Third, and this is the constraint that matters, the feature relies on extension APIs and is not available to the user script.

So the two distribution forms of this project are no longer equivalent. The extension can resolve goto URLs, the user script cannot, and the README history entry for August 2026 makes that explicit with the phrase in extension only. The user script remains the lighter option for the older redirect, and the extension is the one that keeps working as Google changes the scheme.

The options page is where that choice lives, together with the rest of the extension's settings. options.html and options.js are both in the repository, alongside a main_world_script.js and a contentscript.js, so the settings surface is small and readable rather than hidden in a configuration file.

Referrer hiding was dropped and then restored with policies

The history section records a fifteen year arc that explains a lot about the current design.

December 2011 was the first release, as a user script. November 2012 brought the Chrome extension. In April 2013 the Chrome extension was updated to disable the a ping attribute, and that version worked fine for three years without any modifications. In July 2016 the Firefox addon was published, and the program was rewritten from scratch to recognize more URLs and to use modern techniques for a better performance.

Then in September 2016 referrer hiding functionality was restored with minimal impact using referrer policies. In June 2021 the user script was published on Greasyfork. In August 2026 support for goto URLs arrived, in the extension only.

The referrer story is the interesting one. The ping attribute is a mechanism for firing a background request to a tracking endpoint when a link is clicked, and suppressing it is a straightforward job of removing the attribute. Referrer hiding is different, because it is about the Referer header sent with the navigation request, and removing it entirely would break sites that rely on it.

The restoration therefore used referrer policies rather than stripping the header, and the README notes that this was done with minimal impact. The link to Mozilla's post on referrer policy explains the mechanism. The point for a user is that the extension addresses the tracking that the redirect itself creates and the referrer that would otherwise accompany the navigation, using the modern mechanism rather than a blunt one, and that both are handled at the anchor level.

The 2016 rewrite is worth noting for a different reason. The Firefox addon was not a port of the Chrome extension but a from-scratch rewrite to handle more URL shapes and to use modern browser APIs for performance. That is why the repository has separate manifest handling for the two browsers, which is the subject of the build.

Four ways to install, and only one of them needs a browser extension

The project publishes four distributions, and the difference between them is a matter of privilege rather than of features.

The Firefox addon is on addons.mozilla.org, and the README notes that Firefox on Android is also supported. The Chrome extension is on the Chrome Web Store, and there is an Opera version on the Opera addons site. The fourth is a user script on Greasyfork.

The user script is the interesting one for an adopter deciding how much they want to install. It runs in the page rather than as a browser extension, so it needs no permissions and no extension review, and it works in any browser with a userscript manager. What it cannot do is use the extension APIs that the goto resolution depends on, which is why the goto feature is extension only.

So the choice is between a userscript for the older redirect and an extension for the current behaviour of Google search. The extension gets the feature that keeps the tool working as Google changes the redirect scheme.

There is also a note in the history that the original 2011 release was itself a user script, hosted on userscripts.org, and the June 2021 Greasyfork publication is effectively a return to that form after the script had been absent for years.

For anyone who wants to see what the tool does before installing it, the repository carries a screenshot.png at the root alongside the icons, and the README links the demo at the top of the file.

The build is a zip, and Firefox needs a different manifest generated at build time

The Makefile at the repository root is the whole build system, and it is short enough to read in one go.

all: build firefox
build:

The zip target collects the extension files into dont-track-me-google.zip, and the Firefox target then does something extra. It copies the zip to a Firefox-named file, creates a temporary directory, runs node tools/make-firefox-manifest.js to generate a Firefox manifest, and updates the zip with that manifest.

The reason is stated in the comments in the file. The repository root can directly be loaded in Chrome, but Firefox uses a different manifest.json, so it has to be built first. The comment also explains an unusual choice: the files are copied rather than built into intermediate zip files, to allow tools such as web-ext run to work. That matters to a contributor who wants to test the addon live with web-ext run instead of reloading a packaged zip each time.

The user script target runs node tools/make-userscript.js, and the clean target removes the temporary directory and both zips.

So a local build is make for the extension and make userscript for the script. The tools/ directory holds the two generator scripts, and the tools/make-firefox-manifest.js script is also listed as a prerequisite of the temporary directory target, so a change to it triggers a rebuild of the Firefox manifest.

The manifest.json at the root is the Chrome manifest, and the generated one is what Firefox receives. The file list in the zip target is the whole extension: manifest.json, background.js, contentscript.js, main_world_script.js, options.js, options.html and the icon files.

Where dont-track-me-google is the wrong tool

The first wrong-tool case is a user whose problem is tracking in general rather than link rewriting on Google search. This is a single-site tool. It runs on the Google results page and fixes the anchors there, and it does not block requests, does not filter other trackers, and does not change what Google records about your search itself. If you want that, you want a content blocker with a tracker list, which is a different category of software with a different threat model.

The second case is a user who does not want the extension to talk to Google at all. The goto resolution sends a request to Google to retrieve the URL behind a goto link, and that request happens on interaction. It is opt-out through the options page, but a user who reads the options page and wants the extension to never contact Google has to turn it off and loses the goto feature in exchange. That is a real trade rather than a defect, and the fact that the request is deferred until you touch a link limits it.

The third case is a search engine that is not Google. The extension is named for what it does and does nothing else, so a user who has moved to another search engine has no use for it at all.

The fourth case is an organisation with an extension allowlist that does not include this one. The extension is published on the official stores, which is what makes it installable, but a locked-down environment will still decide which extensions are permitted, and a small extension with no organisation behind it will not be on an approved list.

On maintenance, the history gives a sense of rhythm. The project has been alive since December 2011, and the last push was on 2026-09-01, with the goto work landing in August 2026. There are no GitHub releases, so a user tracking versions has to watch the repository rather than a release feed, and the store listings are the practical channel for updates. The project is by Rob Wu, and the licence is MIT, which means the code can be read, modified and redistributed, and the build system being a plain Makefile with two small Node scripts means forking it for an internal browser policy is a realistic exercise rather than a rewrite.

Editorial conclusion

dont-track-me-google suits anyone who wants the real URL of a Google search result back, because the redirect is removed at the point of click rather than blocked after the fact, and the link becomes copyable again. It does not suit a user who is willing to live with the redirect but needs something stronger than referrer hiding, since the extension changes link targets rather than blocking network requests. Before installing, read the options page, because the /goto resolution sends a request to Google when you interact with a goto link and you can opt out of that, and note that the /goto support is not available in the user script, only in the extension.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Rob--W/dont-track-me-google on GitHub