Why a Website Still Knows Your City Through a VPN
A site can use browser location permission and your public IP independently: check the origin permission, the OS setting and the stored city.
Two mechanisms can put a city on the screen and only one of them cares where your VPN exits. The browser Geolocation API returns a device position when the page has permission, and an IP lookup estimates a region from the address the request arrived from. A site that shows your real city while the tunnel runs in another country is usually using the first one, or reading a city it stored months ago. Five steps separate those cases.
Step one: decide which mechanism could answer
Start by asking what the page could possibly know. A device position requires an API call and a permission decision, and it produces a precise coordinate. An IP estimate requires nothing from the user and produces a city at best, often a wrong one. A saved account preference requires neither and survives every network change.
Those three sources explain almost every report. A mapping site that centres on your street is using the API. A shop that greets you in the wrong language is using an IP estimate. A news site that keeps showing your home town after a move is using what your account stored.
| What the page shows | Likely source |
|---|---|
| Street-level accuracy | Device position from the Geolocation API |
| City or region only | IP geolocation of the exit address |
| Same city for months | Stored account preference |
| Different result in a private window | Stored permission or cached state |
Step two: read the permission for that exact origin
Browsers remember a permission decision per origin, so a site you allowed last year opens with no new prompt. Review the location entry for that specific site in the browser's site settings rather than the global default, because the global setting only decides what happens when nothing is stored.
Then check the operating system. A browser on a modern desktop or phone also needs the platform's location permission, and a denied platform permission makes the API fail even when the site is allowed. The available position can come from the platform's services, which have nothing to do with the tunnel.
Two technical conditions explain most failures that look like VPN problems. The API requires a secure context, so a plain HTTP page cannot use it at all, and embedded frames can be blocked by the page's Permissions Policy. A denied request is therefore a browser or page-policy result far more often than a network one.
Step three: confirm the exit address with a fresh request
Ask an independent service what address it sees, from the same browser you are testing. A stale tab, a service worker or a cached page can report yesterday's answer, and comparing a fresh response with the site's display removes that doubt.
curl -s https://ifconfig.me
curl -s https://ipinfo.io/jsonRun those from the machine, not from the router, and note the address and country each one returns. If both report the VPN country and the site still shows your home city, the exit is not the source and the remaining candidates are permission, stored data and a leak path.
Leak paths are the third possibility: a browser extension with its own network stack, a split-tunnel route that sends the site outside the tunnel, or an IPv6 path the tunnel does not carry. Each is visible in the request itself, which is why the exit check comes before any settings change. An extension with proxy settings of its own is the one people miss, because it can bypass the tunnel for a single tab.
Step four: look at what the account already stored
Revoking permission affects future access under the browser's rules, and it does not delete a position the service already stored. A saved home city, a delivery address or a profile region stays until the application updates it, and the site can still make an approximate estimate from the exit address.
Look for the site's own location control before concluding that the browser is at fault. Many applications keep a manual region selector that overrides every automatic estimate, and a support agent reading the account record sees that value rather than your current connection.
Where the stored value matters, change it in the account and note the date. That gives you a second data point when the old city appears again. A screenshot of the account page before the change is worth more than a description of it afterwards.
Step five: change one variable at a time
Test in a fixed order: fresh exit check, origin permission, platform permission, account setting, then a different browser profile. Changing several at once makes the source unidentifiable, which is how a five-minute answer becomes a week of speculation.
Record what you changed and what the page displayed afterwards. If the display only changes in a private window, the cause is stored state; if it never changes, the page is using an IP estimate or an account value that the browser cannot influence. Keep the before and after in the same note, because the pattern is the evidence.
Keep the conclusion honest: a VPN changes the address a request arrives from, and the Geolocation API is a separate permissioned channel that the tunnel does not touch. Both facts can be true at the same time, and most confusing reports come from treating them as alternatives.