Does a VPN change your browser fingerprint? What to test first

You switch the VPN to another country, reload the shop, and it still greets you by name with the same basket. That is the moment the word fingerprint tends to enter the conversation, usually followed by a test site claiming your browser is one in a million. Work the problem in order instead: for ordinary page requests the tunnel changes exactly one field, the browser keeps reporting dozens, and the test measures something narrower than it sounds. Five steps separate those three things.

Step 1: rule out the boring reasons you were recognised

Start signed out. Open a private window, visit the same page, and see whether it still behaves as if it knows you. Cookies, local storage and a live session account for most "it saw through the VPN" reports, and none of them is fingerprinting.

If the page still recognises something in a private window, look at the visible state you carried over: the same account in another tab, a saved form entry, a password manager filling in your address, or a site you authorised with a token in the URL. Each is a stored reference, and clearing the profile removes it.

Only when a clean profile with no session still produces recognition that correlates with earlier visits is it worth talking about a fingerprint. That is a much narrower claim than "the VPN does not work", and it is the one you can actually test.

Step 2: change the exit and list what did not change

Bring the tunnel up, then check the one value the tunnel is meant to move: the address a server sees. Any address lookup page shows it, or read it from an endpoint you control with curl -s https://your-endpoint.example/ip. Whatever echo service you use sees the request, so an endpoint you own keeps that out of someone else's log. Confirm it changed. Now the interesting part — list what the browser still reports about itself, because almost none of it travels in the packet header.

The timezone row is the one worth pausing on. It is read from the operating system, so a tunnel that moves your traffic to another continent while the clock still says your home city produces a mismatch that is itself a distinguishing observation. The same applies to a language list in one locale and an exit in another: not proof of anything, just a combination that stands out. WebRTC is the exception in the table: a page that opens a media or data channel can gather candidate addresses, and with the tunnel up a candidate may carry the exit address or, without leak protection, still offer your local one.

Step 3: read a fingerprint test for what it reports

EFF's Cover Your Tracks is the usual first stop. It shows characteristics your browser exposes to that page and gives a verdict about how many browsers in its sample share them. Read the fine print: the sample is the people who ran the test, the signals are the ones that page chose to collect, and the verdict is a bits-of-entropy estimate, not a census.

So "your browser is unique" means unique among that dataset, today, with that set of probes. It does not mean a website can derive your name, and it is not a permanent property — a browser update can move the value without you touching anything.

Use the test as a measuring instrument, not a score to optimise. Record the reported values, change one thing, and compare the same fields. If nothing changed in the browser, and the readings moved anyway, the change was noise in the sample, not in you.

Step 4: change the characteristics that are actually yours

Now you can act on specific rows. The language list, the timezone and the regional formats are settings, and aligning them with where you claim to be is coherent behaviour rather than a trick. A separate browser profile per context keeps site data and logins apart, which addresses the recognition in Step 1 more reliably than any anti-fingerprinting extension.

Go carefully with the classic advice of adding hardening extensions. Each one changes your observable surface, and a set of unusual settings can make you rarer rather than more ordinary. Some block an API that pages can detect as missing; others leave a distinctive patched signature. Popularity of an extension is not evidence that it reduces identifiability.

Browsers that take this seriously do something structurally different: they standardise. Tor Browser aims to make every user report the same values, Firefox ships a protection mode that reports standardised values from a small set instead of your real ones, and Safari restricts what sites can read. That is a design decision applied consistently, and the guidance in the W3C fingerprinting guidance explains why standardising beats per-user randomisation for this problem.

Step 5: decide which layer you actually needed

Three separate things get bundled into "hide me": the network path, the browser's observable surface, and your accounts. A VPN addresses the first. It does not touch the second, and it cannot help with the third — logging in is the most direct identifier there is, and it survives every exit change.

If your goal is that a site cannot tell two visits are related, you need the browser layer as well: a clean profile per context, consistent settings, and no shared login. If your goal is that the site cannot tell who you are at all, that is a threat model where Tor Browser, which bundles routing with browser-level standardisation, is the coherent choice rather than a normal browser behind a tunnel.

If your goal is only that the site sees a different city and your ISP sees nothing, the tunnel alone is genuinely sufficient, and the fingerprint test result is irrelevant to that goal. Most disappointment here comes from buying one layer and expecting three.

An order that keeps the steps honest:

• Reproduce recognition with a clean profile and no login before blaming the tunnel.
• Confirm the exit address changed, then note which browser values did not.
• Compare the same test fields before and after a single change, not the headline score.
• Fix timezone and language to match your story before adding any extension.
• Pick the layer that matches the goal: network, browser surface, or accounts.