If Everything Is Already Encrypted, What Is a VPN For?
Transport encryption protects the contents of your connection to each site; a VPN hides the existence and destination of those connections from your local network and your ISP. Both are encryption, but they cover different things, and the near-universal adoption of HTTPS has shrunk the VPN’s job to the part HTTPS never handled: metadata. That remaining part is real, but it is much narrower than the pitch most people were sold.
Getting this relationship straight is the most efficient way to understand what you are and are not buying.
What HTTPS covers
When your browser makes an encrypted connection to a site, it establishes keys with that specific server and encrypts everything of substance that follows.
Protected: the page path you requested, the contents of the page, form submissions, cookies, credentials, uploads and downloads. An observer on the path sees an opaque stream.
Also protected: integrity. An intermediate network cannot silently modify the page, insert content, or downgrade the connection without producing an error.
And: identity of the server. Certificate validation means your browser verifies it is talking to the site it intended to, which is what defeats straightforward interception.
This is per-connection and end-to-end. Nothing between you and the server can read it — not your ISP, not the café, not the VPN provider if you use one.
What HTTPS does not cover
Which server you are talking to. The destination address is in every packet by necessity, and reverse lookups usually map it to an organisation. Even where a single address hosts many sites, the address itself narrows things considerably.
The name you looked up. DNS resolution happens before the encrypted connection exists. Historically it travelled in plain text to whichever resolver your network handed you, which meant your ISP or local network had a tidy log of every hostname you visited. Encrypted DNS has improved this substantially where it is enabled, and it is worth knowing whether yours is.
The shape of your traffic. Timing, sizes, and connection counts remain visible. This is less obviously sensitive and more informative than people expect.
Anything not using HTTPS. Some apps, some devices, and some background services still do not.
Everything in this list is metadata, and metadata is what the VPN addresses.
Where the VPN sits relative to HTTPS
They stack rather than compete. With both in use, your traffic is encrypted twice over different spans:
- The HTTPS layer runs from your browser to the site’s server, all the way through the tunnel and out the other side. The VPN provider cannot read it.
- The VPN layer runs from your device to the VPN server, wrapping everything including the HTTPS traffic and the DNS queries.
From the local network’s point of view, all it can see is an encrypted connection to one address. From the site’s point of view, the request arrives from the VPN server. From the VPN provider’s point of view, it sees your real address and the destinations you asked for — but not the contents, because HTTPS is still doing that job.
That last point is the useful one, and it is often missed in both directions. Your VPN provider is not reading your emails; it also does have the list of services you connected to. Both facts follow from the layering.
What this means for the “hackers stealing your password” pitch
That claim described a real risk in an era when much of the web was unencrypted. It is no longer a good description of what happens on a public network, because the credentials are inside the HTTPS layer, and the local network cannot see inside it.
The remaining honest version is: on an untrusted network, a VPN prevents the operator from learning which services you use. That is a genuine benefit, spelled out in what a VPN changes on public Wi-Fi, and it does not need the exaggeration.
Does encrypted DNS make a VPN redundant?
Partly, in one specific respect. Encrypted DNS — sending your lookups over an encrypted connection to a resolver rather than in the clear — removes the hostname list from your local network and your ISP. That was one of the two metadata channels a VPN closes.
What it does not remove is the destination address of the connection itself. Your ISP still sees that you opened a connection to a particular server, and can usually work out whose it is. A VPN closes that channel too, at the cost of handing the same information to the VPN provider.
So the honest ordering is: enable encrypted DNS regardless, since it is free and costs you nothing in trust beyond the resolver you choose. Add a VPN when you also want the destination addresses hidden from your network provider, accepting the trust relocation that comes with it.
The decision this leaves you with
The question is no longer “am I encrypted?” — you are, for content. It is: who do I want to have the list of places I connect to?
Without a VPN: your ISP, and whoever runs the network you are on.
With a VPN: your VPN provider.
That is the entire trade, and it is why what a VPN protects against frames the decision as relocating trust rather than removing an observer. On a hotel network the answer is easy. On your own connection it is a genuine judgement call about which company you would rather have that list.
One practical caveat: the trade only holds if the tunnel actually carries everything. A connected VPN still leaking DNS queries to the local resolver gives the network the exact information you were trying to withhold, while producing a reassuring connected icon. That failure mode, and how to check for it, is covered in VPN leaks and kill switches.