HTTPS vs VPN: do I still need both?

The HTTPS vs VPN question gets asked a lot now that nearly every site has TLS. The reasoning sounds tight: "If my browser shows the padlock, my traffic is encrypted, so why pay for a VPN?" The reasoning is also incomplete in a specific way that this piece is going to walk through.

Short answer up front: HTTPS encrypts the contents of what you send to a specific website. A VPN encrypts the metadata about which websites you visit, when, how often, and from where. They sit at different layers of the network stack and they protect against different kinds of observers. They are complementary, not redundant.

What HTTPS protects

When you load https://example.com/private-page, TLS does three things between your browser and example.com:

Authenticates the server. The TLS handshake verifies that you are talking to the real example.com, not an impostor.
Encrypts the content. Anything sent inside the connection (URL path, headers, body, cookies) is encrypted. Your ISP cannot read the page contents. A coffee-shop attacker on the local Wi-Fi cannot read it either.
Protects integrity. The connection has cryptographic integrity checks, so an attacker cannot quietly modify the bytes in flight without breaking the connection.

That is a lot. HTTPS coverage is genuinely strong. As of 2026, more than 95% of the open web is HTTPS-only, and modern browsers warn loudly on the few exceptions.

What HTTPS still leaks

The "encrypted content" claim is true. The "encrypted everything" claim is not. Several pieces of metadata leak from a typical HTTPS connection:

SNI (Server Name Indication)

When your browser starts a TLS handshake to a site, it tells the server which hostname it wants to connect to. This is necessary because one IP often hosts many sites, and the server needs to know which certificate to send back. The hostname is sent in the clear at the start of the handshake.

Anyone watching the network sees the hostname. Your ISP knows you connected to nytimes.com even though they cannot read what article you are reading. Your network operator at the airport sees the same.

Encrypted Client Hello (ECH) is an in-progress fix for this. Cloudflare, Google, and Mozilla support it. Most of the web does not yet. As of 2026, SNI is plaintext for the vast majority of sites you visit.

DNS queries

Before your browser can connect to nytimes.com, it has to resolve the name to an IP. By default, this query goes to your ISP's DNS server in plaintext. Your ISP sees the resolved hostname even before SNI ever happens.

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) fix this for users who configure them. Firefox does DoH by default in some regions. Most users on most platforms still use plaintext DNS. We have a deeper piece on how DNS leaks expose location that walks through the failure modes.

Destination IP

Even if SNI is encrypted and DNS is private, the destination IP address is in the clear. It has to be: routers along the path use it to forward packets. An observer mapping IP-to-domain (which is trivial; rDNS, Censys, Shodan, even just running a crawler) can usually figure out which site you are visiting from the IP alone, especially for sites on dedicated infrastructure.

The exception is large CDN-hosted sites where one IP serves thousands of domains (Cloudflare's anycast addresses, AWS CloudFront edge nodes). In that case, the IP alone is not informative. SNI usually fills in the gap.

Traffic shape

Even if all the above were perfectly encrypted, an observer can fingerprint the kind of activity by watching packet sizes, packet timing, and connection patterns. Streaming video has a recognisable burst-and-quiet pattern. Video calls have a steady bidirectional flow at characteristic rates. Loading a typical web page is a flurry of small requests followed by a large download. Sophisticated traffic analysis can identify specific sites and even specific videos from this fingerprint, especially for high-traffic destinations with cacheable content.

This kind of analysis is rare in practice for individual users and common for state-level adversaries. Worth knowing it exists.

Connection metadata

Time of connection, duration, and byte counts are all visible to the network. Your ISP knows you connected to something at 9:47pm and stayed connected for 23 minutes and transferred 47 MB. Even with everything else hidden, the existence and pattern of the connection is metadata.

What a VPN protects

A VPN tunnel encrypts your entire network connection between your device and the VPN server. Your ISP, the local Wi-Fi operator, the captive portal, and anyone else watching the path between you and the VPN server only sees encrypted bytes flowing to the VPN provider's IP.

That means, from the perspective of your ISP:

They see one connection, to the VPN server's IP.
They cannot read the SNI of any site you visit, because all SNI data is inside the encrypted tunnel.
They cannot read your DNS queries, because DNS happens inside the tunnel and resolves through the VPN provider's resolver.
They see the traffic shape of one big aggregated connection (browsing, streaming, calls, all multiplexed inside the same tunnel), not the per-site shape they would see otherwise.

What they still see: that you have a VPN connection, the VPN server's IP, the time you connected, the duration, and the total bytes transferred. The metadata about your VPN connection itself is visible. The metadata about what you do inside it is not.

The trust shift

A VPN does not eliminate the observer problem. It moves the trust boundary.

Before a VPN, your ISP sees everything: the IP-level destinations, the SNI, the DNS, the traffic patterns. After a VPN, your ISP sees nothing useful, but the VPN provider sees what the ISP used to see. The VPN provider becomes the new ISP for privacy purposes.

Whether that is a privacy improvement depends entirely on whether you trust the VPN provider more than your ISP. Reasons to trust a paid VPN provider more than a typical ISP:

The VPN's business model is privacy. If they get caught logging or selling data, customers leave. The ISP's business model is connectivity, often subsidised by ad targeting and data sales.
Reputable VPNs have privacy-friendly jurisdictions, audited no-logs claims, and clear policies. Most ISPs do not.
VPNs do not have a regulatory mandate to retain connection data. Many ISPs do (UK, Australia, parts of the EU).

Reasons to be cautious:

The VPN provider can in principle log everything. The privacy gain is conditional on their honesty and operational competence.
Free VPNs in particular often have business models that monetise user data. A free VPN is usually a privacy downgrade compared to a major ISP.
Audited claims age. A provider that was clean three years ago may have changed ownership, infrastructure, or staff.

For us specifically: we do not yet have an independent third-party audit of our no-logs claims. We have committed to one in 2026 and will publish the results in full. Until then, we are an unverified provider asking you to trust us, and we recognise that is a real limitation. Take the same skepticism to any provider that has not yet been audited.

When HTTPS alone is enough

Honest take: for a lot of users in a lot of situations, HTTPS alone covers what they actually care about.

If you are at home on an ISP you trust, in a country that does not aggressively retain or monetise ISP data, and you do not particularly mind your ISP knowing the domains you visit, HTTPS handles the threat model. The VPN adds privacy that you may not personally value at the cost of money and a small speed overhead.

The honest case for a VPN is when one of the following is true:

You are on a network you do not control or trust (hotel, cafe, airport, conference).
Your ISP is in a jurisdiction that retains or sells connection data.
You have a specific destination you do not want associated with your real IP.
You want to access content that is geo-blocked from your real location.
You are in a country that filters or blocks parts of the internet.

If none of those apply to you, HTTPS alone is reasonable. Our do I actually need a VPN write-up walks through this question more carefully.

When HTTPS plus a VPN matters

The two together cover the things neither one covers alone:

HTTPS protects the contents of the page from everyone, including the VPN provider.
The VPN protects the metadata about which pages you load from your ISP.
HTTPS authenticates that you are talking to the real site, not a fake.
The VPN protects against a malicious local network attacker who would otherwise see SNI, DNS, and traffic shape even though they could not read the encrypted content.

Used together, the only meaningful observer left is the destination site itself (which sees the request because it is the request) and the VPN provider (which sees the encrypted-to-the-destination bytes flowing through its server but cannot read inside the HTTPS layer).

Practical takeaways

HTTPS is necessary, not sufficient, for network privacy.
A VPN does not replace HTTPS. They protect different things at different layers.
The "I have HTTPS, I do not need a VPN" framing assumes the only thing worth protecting is page content. Metadata is its own privacy concern.
The "VPN protects everything" framing is also wrong. A VPN moves your trust to the provider; it does not magically encrypt content the destination would have seen anyway.

If you want a deeper take on what an ISP can actually see without a VPN, we have a piece at what your ISP sees without a VPN. For the broader privacy picture, VPN myths debunked covers the most common misconceptions in one place.

The two technologies are layers in a stack, not competitors. Run both.