Short answer: your ISP can see which sites you connect to, but not what you do on them — as long as the site uses HTTPS. On October 30, 2026, I tested this directly with a logging relay between my own computer and my own test servers, in exactly the position an internet provider sits. It saw every domain I looked up, my full login details on an unencrypted HTTP connection, and — on HTTPS — only the site's name and an unreadable stream of encrypted bytes. Nothing here was captured from anyone else's traffic; every test ran on my own machine, with my own data.

Why your ISP is in the perfect spying position

Every byte you send online passes through your provider's network. That gives the provider three things to look at: the address your traffic is going to, the name of the site you asked for, and — if nothing encrypts it — the content itself.

One note on method. This VM does not allow raw packet capture — tcpdump refused with "Operation not permitted" — so instead I built a small logging relay: a program that forwards traffic between a client and a server while writing down every byte that passes through. That is the same vantage point a provider has, except all the traffic was mine, on my own machine.

Test 1: Your DNS lookups are an open book

Before your computer connects to a site, it asks a DNS resolver to turn the site's name into an IP address. That question is usually sent in plain text. I proved it with a toy resolver — a tiny program on my machine that saves incoming DNS queries. I pointed dig at it and asked for example.com: the query was 52 bytes long, with the domain sitting inside it in plain, readable text — literally the bytes for "example" and "com", nothing encrypted around them.

That matters because your resolver is normally run by your ISP, or by your router forwarding to it. Every visit starts with a lookup, so a log of your DNS queries is effectively a log of the sites you visit. Classic DNS was never designed to be private (see Cloudflare: What is DNS?).

The fix is encrypted DNS, and I verified it works: a DNS-over-HTTPS (DoH) query to Google's public resolver came back over HTTPS with the correct answers for example.com. With DoH, an observer sees only an encrypted connection to the resolver — not the name asked about. Cloudflare documents the approach in its DNS over HTTPS guide, and Google in its Public DNS DoH documentation. Most browsers offer it as a "secure DNS" setting — and whoever runs your resolver can read plain DNS queries unless you switch it on.

Test 2: On HTTP, everything is readable — including passwords

Next I ran a plain HTTP server on my own machine, put the relay in front of it, and submitted a test login form through it. The relay's log contained the entire request in clear text — request line, headers, and the form body with my test credentials exactly as typed. The reply was equally readable: the full page, in plain text.

This is the nightmare scenario for public Wi-Fi, and it is not theoretical: anyone between you and the server on an unencrypted connection — the café's router, another device on the same network, your ISP — sees the same bytes my relay saw. A login sent over HTTP is a login handed to the network. Major sites rarely do this anymore (browsers flag them "Not Secure"), but small sites, captive portals, and some apps still use plain HTTP, and every one leaks this way.

Test 3: On HTTPS, the content vanishes — but the site name survives

Then I repeated the experiment over HTTPS, with a local server using a self-signed certificate and a page containing a fake account balance. The relay logged 3,152 bytes in total:

  • The site's name: visible, exactly once. The hostname appeared once, inside the TLS handshake — the setup where the client tells the server which site it wants. This is the Server Name Indication (SNI); Wikipedia's SNI article explains why it is sent in the clear: the server needs it to pick the right certificate before encryption starts.
  • The page itself: completely invisible. I searched the log for the page's text — the welcome message, "Account balance", the balance figure — and found zero matches. The page reached my browser intact, but everything after the handshake was encrypted gibberish to the relay.
  • The destination: visible as an IP address. The relay knew which server it was forwarding to, just as your ISP knows the IP your traffic is sent to.

So your ISP can see that you visited a site — but not which page you read, what you typed, or what you watched. That is the whole point of HTTPS, confirmed here byte for byte. Work to encrypt even the SNI is still rolling out, so assume the site name leaks for now.

What a VPN changes — and what it does not

A VPN does not make you invisible; it moves the trust. Without one, your ISP sees the site names and destination IPs above. With one, your traffic is encrypted between your device and the VPN server, so your ISP sees only an encrypted stream to the VPN's address — no DNS lookups, no SNI. But the VPN provider now sits in the ISP's old seat and sees the same things the ISP used to. Cloudflare's VPN explainer describes this handoff plainly.

Three rules follow. A VPN hides your browsing from your ISP, not from the internet: sites still see your traffic arriving from the VPN, and your logins still identify you. "No logs" is a marketing claim, not a technical guarantee — it cannot be verified from outside, so treat it as a promise, not a proof. And a VPN is no substitute for HTTPS: on an HTTPS site your content is already encrypted against the network, VPN or not. Its real value is hiding the metadata — which sites you visit.

The EFF's Tor and HTTPS explainer adds that Tor and HTTPS protect different things and work best together: Tor hides who visits which site, HTTPS hides what happens there. I tried to test Tor, but the client on this VM never finished bootstrapping (circuit build timed out after 60 seconds), so I report no Tor numbers rather than inventing them.

FAQ

Can my ISP see my search history? It can see that you visited a search engine, but if the engine uses HTTPS (all major ones do), it cannot see the words you searched for. Your browser's own history lives on your device, not at your ISP.

Does incognito mode hide me from my ISP? No. Private mode only stops your own browser from saving history and cookies on your device. Your traffic still travels through your ISP exactly as before.

Does HTTPS hide the site I'm visiting? Only partly. It hides the pages and everything you do on them, but the site's name still leaks through DNS (unless encrypted) and SNI, and the destination IP is always visible.

Conclusion

Your ISP is not reading your messages or watching your videos — HTTPS already stopped that. What it can still see, plainly and by design, is a list of the sites you visit: through your DNS lookups, the SNI in your TLS handshakes, and the IP addresses your traffic is sent to. My tests put numbers on that: a 52-byte DNS packet with the domain in clear text, an HTTP login readable word for word, and an HTTPS exchange where the site name appeared once and the page content zero times.

Close the gaps in order of ease: use HTTPS sites for logins, switch on encrypted DNS, and only then consider a VPN — understanding that a VPN moves your trust from your ISP to the VPN provider rather than removing it.

How this article was made

All hands-on tests ran on October 30, 2026, on a Linux VM (Ubuntu, Python 3.12.3, curl 8.5.0, dig 9.18.39). I built a logging TCP relay and a toy DNS listener in Python, ran my own local HTTP and HTTPS servers, and recorded what the relay could read: the full HTTP login in clear text; 3,152 logged bytes for the HTTPS exchange, with the hostname once (SNI) and the page text zero times; and a 52-byte DNS query with the domain in clear text. A DoH query to Google's resolver returned correct answers over HTTPS. The Tor client (0.4.9.11) never bootstrapped on this VM, so no Tor results are claimed. Background on DNS, DoH, SNI, and VPN concepts comes from the linked documentation, not from my tests. Drafted with AI assistance and checked against the test logs before publishing.