What a VPN Hides, and What It Leaves in Plain Sight
A VPN hides your destination from the access network and swaps your exit IP. It does not hide accounts, cookies, device state or what the operator sees.
The claim that a VPN makes you anonymous is the most expensive myth in consumer privacy, because it is half true and the false half is the half people rely on. A tunnel does hide your destination from the network you are sitting on, and it does hide your home address from the site you visit. It does not hide who you are when you sign in, what your browser carries, or what the VPN operator can observe. The useful question is never whether a VPN hides you, but hidden from which observer, for which traffic.
The myth: a tunnel is an anonymity switch
A VPN encrypts the path between your device and the VPN server, then forwards your requests from the server address. Everything you send through that path is hidden from the Wi-Fi operator and the ISP in front of the tunnel. That is a real change, and it is why a hotel network no longer sees which sites you open. It is not anonymity, because the tunnel moves the point of observation instead of removing it.
The correction matters in practice. If you sign into a work account over a VPN, the site still knows the account. If your browser holds a cookie from an ad network, the tunnel does not clear it. If the client is configured to exclude local traffic, that traffic never enters the tunnel. A connected padlock describes the tunnel, not the sum of what you revealed.
What the access network loses and keeps
The access network, meaning the Wi-Fi operator or ISP that carries your connection to the VPN server, still sees that a VPN connection exists. It can log the endpoint address, when you connected, how long the session lasted and roughly how much data moved. Traffic analysis of that shape can be informative even when content is unreadable, which is why encrypted and invisible are different claims.
It also keeps anything you told it directly: a captive-portal login, a room number, a payment for access. And it may still see DNS if the client or system resolver sends queries outside the tunnel. That leak is common on split-tunnel setups and on devices that keep a router or carrier DNS server. Check the resolver in use while connected, not just the exit address.
| Observer | Still sees | Hidden by the tunnel |
|---|---|---|
| Access network | VPN endpoint, timing, volume, portal login | Destination hostnames and content |
| Website | Exit address, account, cookies, fingerprint | Your ordinary public address |
| VPN operator | Destination IP, often the hostname, DNS if used | HTTPS content, unless it intercepts TLS |
| Device | History, app data, permissions, screen | Nothing |
What the website still recognises
The site sees the exit address of the VPN server, not your home address, for connections that use the tunnel. That is the whole of the IP-level change. What it sees beyond the address is unchanged: the account you sign into, cookies it set earlier, the browser and operating system you present, and the timing of your requests. A site that already knows you does not become a stranger because the source address changed.
Location deserves its own line. A site that asks the browser for location gets an answer controlled by the browser permission, not by the VPN. GPS on a phone is independent of the tunnel. An address that geolocates to another country while the map still shows your city is therefore not a VPN failure; it is two different location channels disagreeing.
Fingerprinting is the other half. Screen size, fonts, time zone, language and canvas output can distinguish browsers even when the address is shared with thousands of other users. A VPN changes one input to that profile and leaves the rest intact.
What the operator can see
The operator terminates your tunnel and forwards the request, so it sits where your ISP used to sit. It can see destination addresses and, without encrypted client hello, the hostnames you request; it sees DNS queries if you use its resolver; it sees volume and timing. It cannot read the contents of an HTTPS session without intercepting it with a certificate your device trusts, which is a different and noisier attack.
Visibility is not retention. A provider may be technically able to observe a request and still not log it, or may log connection metadata while discarding content. The honest question is what the provider policy and jurisdiction require it to keep, and a no-logs badge does not answer that. Treat the operator as a party you choose to trust with your metadata.
What the device keeps, tunnel or not
Nothing about the tunnel reaches inside the device. Browsing history stays in the browser, downloads stay in the filesystem, and an app with microphone or screen access keeps that access. Monitoring software on the machine can read data before it is encrypted or after it is decrypted, which is why a VPN is not a defence against a compromised endpoint.
The same applies to accounts. A session cookie copied from the device works from any address, and a password reused across sites links identities that no tunnel separates. If the threat you care about is someone holding the device, the VPN does not address it.
Test the coverage you actually bought
Test the properties you rely on instead of the marketing claim. With the tunnel up, check the public address, the DNS resolver and the IPv6 path. An IPv4-only tunnel on a dual-stack network can leave IPv6 traffic outside it entirely. EFF''s guide to choosing a VPN frames the same question as a threat model rather than a product ranking.
Then test failure behaviour. Disconnect the tunnel and confirm whether traffic stops or falls back to the direct path; that depends on the client kill-switch setting, not on the protocol name. Finally, list the apps and prefixes the client excludes. Split tunnelling is where most surprises live, because the coverage you bought is the coverage the client is configured to deliver.