Why a VPN Exit and Your Browser Language Disagree

Open the developer tools, load the page, and read the request headers before you conclude anything about the VPN. You will usually find an Accept-Language line asking for a specific set of languages, and that line came from your browser settings, not your exit address. A French speaker on a Tokyo exit still sends French, and a site answering in French is answering the header. The tunnel is not leaking just because the page arrived in a familiar language.

Read the header before anything else

In a desktop browser, open the Network panel, reload, click the document request and look under request headers. From a terminal you can see the same thing without a browser, and you can override the value to test the site's behaviour:

curl -sS -D /tmp/h1 -o /tmp/b1 https://example.com
curl -sS -D /tmp/h2 -o /tmp/b2 -H 'Accept-Language: fr,en;q=0.6' https://example.com
grep -o 'lang="[^"]*"' /tmp/b1 /tmp/b2
diff /tmp/b1 /tmp/b2 | head -40

Now the body is on disk, so the comparison is about the page rather than about a header that may never be sent. Look at the html lang attribute and at the visible text, because Content-Language is optional and plenty of servers omit it. A site that switches the whole page from English to French on the same URL can therefore look unchanged in a header-only diff. If the document language follows the header while the exit stays fixed, the header was the deciding input and the VPN is irrelevant to that observation.

Use a second browser profile rather than the site's own language switcher for this test. A switcher usually writes a cookie, which is a different input, and you will end up measuring the cookie instead of the header.

What the q-values mean, and what they do not

RFC 9110 section 12.5.4 defines Accept-Language as a list of preferred natural languages for the response. Each entry can carry a weight from 0 to 1, a range without a weight has weight 1, and a weight of 0 marks a language as not acceptable. That is a preference order, nothing more.

The value is not a location report, not a confidence score and not an identity. A server is free to ignore it, to serve the only translation it has, or to let a country redirect win. Content negotiation is the server's choice, and the header is an input to that choice rather than a command.

This is the part people miss when they treat a localised page as a location test. The header states which languages the person prefers to read, and a preference can travel anywhere.

Three inputs decide the language you actually get

Isolate them one at a time, because from the outside you cannot see which one won:

• The header. Test with a second profile configured for a different language list, and watch the page change with everything else held constant.
• A stored choice. Test in a private window with no cookie, or clear the site's storage. Account settings and localStorage entries can pin a language for months.
• A URL or redirect. Test by requesting the explicit language path, such as /fr/, and by watching the status codes for a redirect based on the source address.

Run the three tests in that order and write down which one moved the result. A single page load that changes language after you enable the VPN is weak evidence, because a redirect and a cached cookie can both produce that impression.

What the VPN changes, and what it does not

The tunnel changes the source address a server sees, and with it anything the server derives from IP geolocation. It does not rewrite the browser's language preferences, clear a stored setting, or change the URL you typed. Those inputs stay exactly where they were, so a page can keep its old language after the exit moves.

Geolocation adds its own noise. Address databases disagree with each other, and an exit registered in one country can be mapped to another, which makes a country-based redirect look wrong for reasons that have nothing to do with your browser.

A quick walkthrough check separates them: request the page fresh, note the address you present, then compare the response language with your header list. If the language matches your list rather than the exit country, the header was the deciding input and there is nothing to fix in the tunnel.

What a localised page does and does not prove

There is a real privacy point here, and it is smaller than the one people usually make. A complete list of language preferences is a fingerprinting input and can reveal something about who you are or what you read. That is a genuine disclosure of preference, and it is not the same as proving that traffic escaped the tunnel.

A localised page is not a leak indicator. If you actually want to test for a leak, check the exit address the site sees, the resolver path used for name lookups, and the candidates a WebRTC stack exposes. Those tests answer the question the page language cannot.

Next time a site appears to know your country, open the request headers first. If the response language matches your browser's list, nothing leaked, and the layer to look at is the one in front of you.