HTTPS hides page content, not everything. Learn what your ISP, Wi-Fi operator, or carrier can still see: destination IPs, DNS, SNI, and traffic patterns.
The padlock in your address bar means the content of the page and the path you typed after the domain are encrypted — not that your connection is invisible. HTTPS was never designed to hide metadata, and metadata is most of what's left for an on-path observer like your ISP, a Wi-Fi operator, or a mobile carrier to work with. This guide walks through exactly what that residue is: the destination IP, the DNS lookup, the server name in the TLS handshake, and the timing and size of your traffic.
Key Takeaways
- HTTPS encrypts what you read and type, not who you're talking to. The destination IP address is visible on every packet, regardless of encryption.
- DNS is usually the biggest leak. Unless you use encrypted DNS, your resolver — often your ISP's — sees every hostname you look up, in plaintext.
- The TLS handshake historically leaked the hostname too, via Server Name Indication (SNI). Encrypted Client Hello (ECH) closes that gap where both browser and server support it.
- Traffic timing, volume, and rhythm leak coarse behavior even when every byte of content is encrypted — this can't be fixed by a browser setting.
- No setting makes you invisible to the network you're on. The realistic goal is an accurate mental model of what remains exposed, not a false sense of total privacy.
The Concrete Split: What HTTPS Encrypts and What It Doesn't
HTTPS wraps your HTTP request and response — the page body, form fields, cookies, and the path and query string of the URL — inside TLS encryption. An observer sitting on the network between you and the server cannot read what you searched for, what you posted, or which article you're reading on a given site. That's the real and significant protection HTTPS provides over plain HTTP.
What TLS does not hide is the envelope: who is sending the packet and who it's addressed to, roughly how big it is, and when it was sent. Those fields have to stay readable for routers to do their job, and that's exactly the information an on-path observer can still collect. The rest of this guide walks through each piece of that residue.
Residue 1: The Destination IP Address
Every packet you send carries the IP address it's headed to, in the clear — TLS encrypts the payload, not the network-layer header that routers use to deliver it. Your ISP (or anyone else on the path) can always see which IP addresses you're connecting to and correlate that against known hosting ranges.
In practice this is a weaker signal than it sounds. A dedicated server with one tenant maps an IP straight to an identity. But most of the modern web sits behind shared infrastructure — CDNs and cloud load balancers that serve thousands of unrelated domains from the same address block. Seeing a connection to a Cloudflare or AWS IP tells an observer "something behind this shared front door," not which of the thousands of sites behind it you actually loaded. Co-tenancy weakens the signal considerably; it doesn't eliminate it, because IP ranges are still sometimes dedicated to a single service, and combined with DNS or SNI (below) the IP often confirms rather than reveals the destination.
Residue 2: DNS — Usually the Biggest Leak
Before your browser can connect to anything, it has to resolve a hostname to an IP address, and that lookup is a completely separate exchange from the HTTPS connection that follows. Unless you've specifically configured encrypted DNS, that query goes out in plaintext to a resolver — by default, one operated by your ISP — which sees the exact hostname you're about to visit, timestamped.
This is the residue most people underestimate, because the browser's own connection is encrypted while the lookup that precedes it isn't. The fix is encrypted DNS (DNS over HTTPS or DNS over TLS), which most modern browsers now support natively. We cover the mechanics, the common misconfigurations that leak DNS even through a VPN, and how to test your own resolver in DNS Leak Prevention — worth reading in full if this is the piece you're most concerned about, since it's usually the highest-value one to fix.
Residue 3: SNI in the TLS Handshake
Even after DNS resolves a hostname, the TLS handshake that sets up your HTTPS connection has historically leaked the same hostname a second time. To let one IP address serve multiple HTTPS domains (again, the normal case behind a CDN), your browser sends a Server Name Indication (SNI) field in its initial ClientHello message, naming the site it wants to reach — so the server terminating TLS knows which certificate to present. TLS 1.3 (RFC 8446) encrypts most of the handshake that follows, including certificates exchanged later in the negotiation, but the ClientHello itself — and the SNI field inside it — has to be sent before any encryption keys exist, so by protocol necessity it traveled in the clear. That's the same ClientHello that TLS fingerprinting reads to identify client software; SNI is a second, independent signal riding in the same plaintext message.
Encrypted Client Hello (ECH) is the fix: it encrypts the sensitive inner ClientHello — SNI included — using a key the server publishes in DNS, leaving only a minimal, generic outer ClientHello visible on the wire. Cloudflare, which operates TLS termination for a large share of the web, announced production support for ECH as part of pushing the standard toward real-world deployment. Be precise about what this actually gets you, though: ECH only closes the SNI leak where both your browser and the server you're connecting to support it and have it enabled — it's a per-connection property, not a setting you flip once and forget. A connection to a site or CDN that hasn't deployed ECH still sends SNI in the clear, no matter how current your browser is.
There's also a dependency that ties this residue straight back to the previous one: the key that encrypts the inner ClientHello is published in a DNS record, so your browser has to look it up before it can encrypt anything. If that lookup travels in plaintext, the hostname has already leaked to your resolver by the time ECH gets a chance to hide it — which is why browsers that ship ECH gate it on encrypted DNS being active for the query. Encrypted DNS isn't a parallel fix you can pick instead of ECH; it's a precondition for ECH working at all.
Residue 4: Timing, Volume, and Pattern
Even a hypothetical connection with the destination IP, DNS, and SNI all fully hidden still leaks something: the shape of the traffic itself. The size of each packet, how many there are, and the rhythm of bursts and pauses between them survive encryption completely untouched, because encrypting a payload doesn't change how many bytes it takes to send it or when you chose to send it.
This is a real, well-studied residue — traffic-analysis research has repeatedly shown that the size and timing pattern of an otherwise fully encrypted session can narrow down, and sometimes identify, what a user is doing. It's also the hardest of the four residues to reason about casually, and not something a browser setting fixes. The practical takeaway is modest: understand that "encrypted" doesn't mean "shapeless," and treat this as a background fact rather than something to chase with a workaround — there's no simple mitigation to recommend here, and this article isn't going to pretend otherwise.
Who Else Is on the Path
Your ISP is the most obvious observer, but it's rarely the only one. A Wi-Fi network operator — the coffee shop, the airport, the hotel — sits in exactly the same position as your home ISP for as long as you're connected to their network. A corporate network typically runs a middlebox that can see the same metadata (and, on managed devices, sometimes more, via an installed root certificate). A mobile carrier sees everything your phone does over cellular data the same way a home ISP sees your router's traffic.
A VPN is the common response to this, and it's worth being precise about what it actually does: it relocates the observation point from your local network or ISP to the VPN provider, rather than removing an observer from the picture. Your ISP now sees only that you're connected to a VPN server, but the VPN provider is now the party positioned to see your destination IPs and, depending on its own DNS configuration, your DNS queries. Whether that's a net improvement depends entirely on trusting the VPN operator more than you trust your ISP — see our comparison of VPNs, proxies, and Tor for how the three common tools actually differ in what they hide and what they still expose. A related, since-retired approach worth knowing about is Chrome's IP Protection, which used a two-hop proxy design specifically so that no single relay operator could see both your real IP and your destination together — a different trust model from a single-provider VPN, even though both are proxies in the general sense.
What You Can Check Yourself
You don't have to take any of this on faith. BrowserInsight's IP intelligence check shows the exit IP and network details a destination server actually sees for your current connection, and the VPN/proxy check reports whether that connection looks like a VPN, a proxy, or a bare residential or business ISP line. Comparing the two before and after connecting to a VPN — or after switching networks — is the fastest way to see which observer currently sits on your path. If you suspect your VPN isn't routing DNS through its tunnel the way it should, DNS Leak Prevention has the exact commands to check which resolver is actually answering your queries, and a related side channel worth ruling out at the same time is covered in WebRTC Leak Protection, since WebRTC can expose your real IP independently of DNS or your VPN's tunnel.
The Honest Takeaway
None of this is a case for panic, and it isn't a checklist for hiding from your ISP — that framing overpromises and this guide isn't going to pretend otherwise. It's a case for an accurate mental model: HTTPS did real, important work by encrypting content, and DNS, SNI, and traffic shape are the metadata that's left over, in roughly that order of how much you can practically reduce. No combination of browser settings makes your traffic invisible to whoever operates the network you're currently on — the goal is understanding what's actually exposed, not a false sense that the padlock icon means nobody can see anything.
Frequently Asked Questions
Can my ISP see which websites I visit if I only use HTTPS?
Not the specific pages or their content, but yes to the domain in most cases. Unless you use encrypted DNS, your ISP's resolver sees every hostname you look up. Even with encrypted DNS, it can often still infer the destination from the IP address and, where Encrypted Client Hello isn't deployed, from the SNI field in the TLS handshake.
Does HTTPS hide the URL from my ISP?
It hides the path and query string — everything after the domain — because those are inside the encrypted HTTP request. It does not hide the domain itself, which is exposed separately via DNS and potentially SNI, as described above.
What is SNI and why does it matter for privacy?
Server Name Indication is a field in the TLS handshake that tells a server which hostname you're trying to reach, needed because one IP address commonly hosts many different HTTPS domains. Historically it traveled unencrypted, exposing the hostname on the wire even though the rest of the HTTPS session was protected. Encrypted Client Hello (ECH) is the deployed fix, but it only works when both your browser and the destination server support it.
Can my Wi-Fi network owner see what I browse over HTTPS?
The same metadata your ISP would see: destination IPs, DNS queries if unencrypted, and SNI where ECH isn't in use — they're in the same on-path position as an ISP for as long as you're on their network. They still cannot read page content or read what you type into an HTTPS site.
Does a VPN stop my ISP from seeing this metadata?
It moves who sees it, not whether anyone does. Your ISP sees only an encrypted tunnel to your VPN provider, but the VPN provider is now positioned to see your destination IPs and DNS queries instead. Whether that's an improvement depends on trusting your VPN provider more than your ISP — see our privacy tools comparison for the full trade-offs.
