What a VPN Hides About Your IP Address, and What It Leaves Alone

A VPN substitutes one thing: the public address that appears as the source of your traffic when it reaches a service. Everything else that identifies you — your accounts, your cookies, the characteristics of your browser and device, the addresses on your own network, and the record of every hostname you look up — is left exactly as it was, unless something else in your setup is also changed. This site is organised around that sentence, because almost every disappointment with a VPN is the gap between “hides my IP address” and what an IP address was ever doing.

What an IP address actually is

It is a routing label. Its job is to let every network between you and a destination decide where to forward a packet next, and to let the reply find its way back. Addresses are allocated in blocks to organisations, those organisations assign them to customers or equipment, and the allocation records are public because routing does not work in secret.

That last part is the key to reading the whole topic. An address is not a secret that a VPN keeps. It is a published, structured identifier whose owner is a matter of record and whose user is not.

What your address does reveal

More than nothing, and reliably:

Who operates the network. The block your address sits in belongs to a named organisation — your provider, a carrier, a hosting company. That is an unambiguous lookup rather than a guess, and the reverse name often describes the equipment or region too. What an ASN and reverse DNS reveal about your connection covers what comes back.
A rough region, with real error bars. Geolocation is a commercial database mapping blocks to places: usually good enough to pick a language, frequently wrong about the city, and badly wrong when a provider reassigns a block.
The kind of connection. Residential, mobile, business, and datacentre ranges are distinguishable, which is why swapping a home address for a server’s reads as a change of category.
That two visits came from the same place. This is what people mean by “tracking by IP”, and it only matters until something better is available.

What it does not reveal

Your name, your street address, your household, or which device in it made the request. A service seeing your address sees your provider and a region. To get from there to a person requires records only that provider holds, and there is no lookup that turns an address into an identity.

It also reveals nothing about the contents of your traffic. That is a different layer entirely.

What a VPN substitutes, precisely

You hold more than one address, and only one of them is affected.

Your private address stays. The 192.168. or 10. address your router gave your device is unchanged, and it has to be — it is how your own network reaches your machine. The scope distinction is in public vs private IP addresses.

Your provider-issued public address stays. It keeps existing and keeps working, because the encrypted connection to the VPN server travels over it. Your provider still sees a connection from you; it simply sees one destination instead of many.

A third address appears. The client’s virtual interface gets an address from the operator’s internal range, identifying your session to the server. Services never see it. Why a VPN gives you two IP addresses is the mechanics.

The exit address is the substitution. Services see the server’s public address. It is shared with everyone else on that server, which is both the privacy benefit and the source of the friction — you inherit whatever behaviour that address is associated with, and it is legible as infrastructure rather than as a home. Shared vs dedicated VPN IP addresses is the trade-off in full.

So “hides your IP address” is better read as “presents a different one, at one specific layer”.

What is untouched: accounts and cookies

If you sign in, the service knows who you are, with total certainty, from an identifier you supplied. No property of the address you arrived from modifies that. The same applies to cookies and stored session tokens: they travel in the request, they identify the browser that stored them, and they are unaffected by routing.

The point to carry forward is about the address rather than about any particular service. As an identifier it is weak — shared by a household, reassigned by providers, and often shared by many subscribers at once. Anything that needs to recognise you reliably therefore uses something stronger, and substituting a weak identifier leaves the strong ones in place.

What is untouched: browser and device characteristics

Your browser volunteers a great deal on every request and via ordinary scripting: which browser and version, the operating system, screen dimensions, installed fonts, language preferences, time zone, and how graphics are rendered. In combination these are distinctive, and none of them travel through anything a VPN modifies.

Two are actively awkward. Time zone and language describe where you actually are, which is why a substituted address in a distant country produces a device that contradicts itself. And your hardware address, invisible to remote services, still identifies your device to the local network — what MAC address randomisation hides, and what it doesn’t sets out that boundary.

What is untouched: your local addresses, if the browser offers them

Browser real-time communication needs to discover your device’s own addresses in order to connect two peers directly, and that discovery can hand over private addresses from your own network. It is a legitimate mechanism doing its job, and it operates independently of what your routing table says. What WebRTC reveals about your local IP address explains the conditions under which it matters.

What is untouched unless configured: name resolution

This is the most common real failure, and it is the reason a whole section of this site is about DNS. Before your traffic goes anywhere, your device turns a hostname into an address by asking a resolver. That query is a separate journey with its own settings, and if the tunnel does not capture it, your resolver keeps receiving a complete list of everything you look up while your traffic is faithfully tunnelled.

Confirming your exit address tells you nothing about this. It is a second, independent check, and who runs your DNS resolver, and why it matters is where to start. There is also a related field that names sites even when resolution is private: what still names the sites you visit.

The same “unless configured” caveat covers a second protocol family. Many setups tunnel one version of IP and quietly let the other take the direct path, which sends some of your traffic out under your own address while the app reports success — see why IPv6 is the leak people forget.

How to use the rest of this site

The structure follows the layers above, so you can go straight to the one your question belongs to.

Addressing. What your addresses are, why they change, what happens when subscribers share one, and which of them a tunnel replaces.
Name resolution. How lookups work, who answers yours, and what your client’s DNS setting really changes.
Leaks and diagnostics. Reading your own interfaces and routes, checking whether traffic is escaping, and what a traceroute looks like on each side of a connection.
Features and protocols. What a kill switch, split tunnelling, or a given protocol does to your routing.
Judging claims. How to test a provider’s technical assertions rather than taking a feature list at its word.

None of that asks you to trust a summary. Every claim here is about something observable on your own machine, which is the only useful standard for a subject where the marketing is this loud.