Who can see what you do online, with and without a VPN

Web traffic to any mainstream site is encrypted in transit by default. A network operator watching a modern HTTPS session can't read the page you asked for, the form you submitted or the credentials you sent. A VPN neither strengthens nor weakens that.

That's worth saying because a lot of VPN marketing implies otherwise. It suggests unencrypted content is the normal state of the internet, and that a tunnel is what fixes it. The content was already encrypted.

What stays legible is metadata, chiefly the identity of the host you're contacting. The name is usually visible during the handshake that sets up the encryption. The lookup that came before it is often visible too.

So an observer on the path can build a list of the services your device talked to, when, and roughly how much data moved. It learns nothing about the contents.

A tunnel mostly changes who can see which hosts you contacted, not who can see what you sent. That's a smaller claim than the advertising makes, and still a meaningful one. The list of hosts you contact over an evening is informative on its own.

Whoever runs the network you join is the closest observer, and often the least accountable. In a café, hotel or airport that operator may be the venue or a contractor. It may be a hardware vendor with a cloud dashboard that nobody on the premises could name.

Without a tunnel, it's positioned to see every hostname your device resolves and every address it connects to. It can also redirect name lookups to its own resolver, as many captive portals do by default.

With a tunnel up, that view narrows. The operator sees a device holding an encrypted session with one address, plus the volume and timing of the traffic. The destinations are inside the tunnel.

It can still tell you're using a VPN, because a persistent encrypted flow to a single endpoint is a recognisable shape. It also still sees the hardware address your device presents on that network.

Neighbours on the same network are a separate matter, and the tunnel doesn't touch it. Where client isolation is missing, as it often is in hotels and holiday lets, other devices can see that yours is present. They can also probe which services it offers.

That exposes the device, not your browsing. The remedy is a firewall and turning off file sharing.

Without a tunnel, your ISP has the broadest and most durable view of anyone. Every connection from your line crosses it, for as long as the account is open.

It sees which hosts you contact and when. It usually runs the resolver that answered your lookups. And unlike a café, it knows precisely whose account the traffic belongs to, because it bills that account.

What does your particular provider keep from all that, and for how long? That's a question about its own policy and the rules where it operates. No single page can answer it for everyone.

With a tunnel, its view collapses to roughly the café's. It sees an account holding a long-lived encrypted session to one address, with volumes and timings. It also knows which provider owns that address.

The host list is gone. That substitution is what most people are actually buying, whether or not anyone described it that way.

Your traffic has to leave the tunnel somewhere to reach its destination. At that point something must know where it's going, because that's what forwarding means.

So the exit is, by construction, in the position your ISP used to hold. It's the party handling the onward connections, and it's able to enumerate them.

The honest description, then, is a swap. Before, the local network and the ISP see the host list, and the destination sees a home or mobile address.

After, those two see an encrypted session to one address. The exit is positioned to see the destinations, and the destination sees the exit's address. No observer was abolished. One was substituted for another.

Is that worth doing? It comes down to comparing the two parties. An ISP knows which account the traffic belongs to because it bills it, and it sits on the line for as long as the line exists.

A VPN provider also knows an account, since a subscription is attached to an email. It doesn't see less by nature. The difference is that it can publish what it keeps, field by field, and be held to that.

On a shared network the comparison is more lopsided still. Suppose you're on a hotel's Wi-Fi. The party you displace is a hotspot operator you can't identify, and for most people in that situation the swap is genuinely an improvement.

It's still a swap. Anyone who describes it as disappearing from the network is selling something.

Being positioned to observe something and recording it are different facts. The second is the one you can check against a provider's own description.

On WrapVPN, our connection log holds one row when a tunnel comes up and one when it goes down. Each row carries the account identifier, a timestamp, the event type and status, which exit was used, the session duration, the platform and the client version. A row can also carry a session ID, a disconnect reason and an error message.

For example, say you connect to our Frankfurt exit at 9:00 and disconnect at 9:40. The log gets one row at 9:00 and one at 9:40, tied to your account identifier and that exit. Nothing in them says where you went in between.

There's no column for browsing activity and none for DNS queries. Not an empty one, and not a redacted one. There's no column for a network address either, so your originating address isn't written into that row. It's stored somewhere else: with the session token that keeps your app signed in, in a record we write each time you sign in, and in our API's request log. All three are tied to your account.

That record makes connection faults investigable. When someone reports that sessions drop on a particular exit, this is the evidence. Nothing in it reconstructs where you went, because none of its fields describes a destination.

Separately, we hold your account: the email, name and Apple or Google ID from your sign-in, and which plan you're on. We also keep a record of each device you use: its name, platform and the exit it last used.

Two qualifications belong here in the body, because that log isn't the only thing we write down. The first is the node aggregate. Each node runs a permanent packet capture, including one on DNS traffic, and ships an hourly usage aggregate built from it to an internal analytics store. It holds byte and request counts, and the external addresses that node talked to, with their country, ASN, ISP and domain names.

The field that identifies a client in those rows is the 10.x address assigned inside the tunnel, not your originating public address. Our console's ready-made views of the store leave that field out or reduce it to a count. Its query box refuses a query that names the field, but a query that asks for every column still returns it. So treat this as a guardrail for staff, not a barrier.

It's still destination data, so the accurate sentence is narrower than a slogan. The per-session log can't place you anywhere. The aggregate was built to answer how much traffic went where, not who sent it. But each node names tunnel addresses by account and device, so don't treat it as anonymous to us. The second qualification is our apps' analytics. They report each session to Google's Firebase under your account ID, and on Android and Windows that report carries the tunnel address, exit, duration and data used.

There's a limit alongside that. Ad and tracker blocking happens at name resolution, so whatever answers a lookup is momentarily in a position to see the name. That's inherent to resolving anything, and it applies equally to an ISP's resolver.

Our claim here is about what we keep, and the raw capture is part of that for a while. It's written to the node's disk as plain text: the addresses on every packet, and every DNS question with the tunnel address that asked it. Each hour's file is normally deleted at the next hourly run, once it's been summarised.

The destination sees your request, because it's the other end of it. Without a tunnel it sees your originating public address, which maps to an approximate location and an ISP. With one it sees the exit's address, which maps to the exit's city and the provider. That's the whole of what changes at this end.

Everything else the destination knows is untouched. A signed-in session identifies your account outright. Cookies set on an earlier visit identify the same browser.

Fingerprinting can still distinguish your device. It combines screen dimensions, fonts, time zone, language, graphics behaviour and more, and a changed address doesn't disturb it.

A site can notice a mismatch too. Suppose your browser reports one time zone while your address geolocates to another continent. That's itself a signal.

The same holds for the analytics and advertising services the page hands data to. DNS-level blocking removes a share of those parties outright by refusing the lookup.

It can't help where a tracker is served from the same domain as the content you wanted. The decision is made on the name, and the name was asked for.

Here's the same list compressed, for scanning. Each entry gives what the party learns without a tunnel, then with one.

A VPN acts on the path between your device and a destination. Four of the most consequential exposures aren't on that path. No tunnel from any provider, at any price, affects them.

Being signed in is the largest. A service you're logged into knows who you are by definition, and the tunnel sits behind the login, not in front of it. Stored identifiers are the second. They travel with your browser and survive an address change.

Fingerprinting is the third, and it's designed to work without any stable network identifier. The fourth is the device itself. Malware, a compromised extension, a management profile or physical access all observe from inside the endpoint. Traffic is already decrypted there, because it has to be for you to read it.

Separate browser profiles, blocking third-party storage and keeping the device clean aren't alternatives to a tunnel. They address different exposures. For most people, that side of the ledger is the larger one.

Three facts should weigh against us if you have a demanding threat model. This is the page that states them.

The first is key custody. Our server issues the tunnel configuration, and it includes the private key. Your device doesn't generate its own pair and keep the secret half local.

That's a convenience decision with a real cost. The node that issues your configuration generates the private key and keeps it in memory while your device's peer is live there. So we hold the secret half, not only the public half. If your model requires that the secret never existed outside your device, treat this as disqualifying. We state it here because you can't discover it from outside.

The second is what happens when the tunnel is stopped. On iPhone, iPad, Mac and Android, nothing holds your traffic once the tunnel is down: it reverts to the ordinary path, and the local network and ISP resume seeing hostnames. Windows is a partial exception. While its tunnel runs, a firewall blocks anything that doesn't go through it, but that lifts whenever the tunnel stops, including the couple of seconds the app takes to restart it.

Pause is the deliberate version of the same state. It comes in fixed intervals: 5, 15 or 30 minutes on iPhone and Mac, 5, 15 or 60 on Android, and 1, 5, 15 or 60 on Windows, alongside Disconnect Completely. An unplanned drop has no safeguard behind it.

The third is retention. Our connection log has no purge job, so rows accumulate. The fields in them don't describe browsing, which bounds how much that matters. Still, a provider stating a short retention window would be making a stronger claim than we can.

The useful question isn't whether a provider offers privacy. Ask which observer you want removed, and whether you'd prefer to be seen by the party that replaces it.

Say you're on hotel and airport networks for a fortnight. You're displacing an operator you can't identify, and a provider that publishes what it records is the more accountable counterparty.

If your concern is your ISP at home, you're making a narrower swap. Read the policy on the other side carefully. If your concern is advertisers, you're looking at the wrong layer, and the effort belongs in the browser.

Three questions separate providers on this axis, and none is about server counts. What's written down, field by field, with no slogan standing in for the list? What happens when the tunnel drops? Where does the key material come from?

A provider that answers all three plainly is telling you something about how it will behave later.