What Does Your ISP See?
Without a VPN your ISP can see every domain you look up and every server you connect to. It cannot read HTTPS pages. The difference matters more than it sounds.
Your ISP can usually see which websites you look up, roughly when, and how much data moves in each direction. It usually cannot read the contents of the pages you load. Both halves of that sentence are true, and the second one is doing far less work for you than people assume.
Short answer#
Without a tunnel, the operator of your network can see:
- Your IP address, and that the traffic belongs to you.
- Every domain name you resolve. A DNS lookup is a question asked in the open.
- Every server you connect to, by IP address and port.
- When, how much, and in which direction.
- The name of the site you are connecting to, in most cases, sent in cleartext as part of the TLS handshake.
What it normally cannot see:
- The contents of an HTTPS page. TLS 1.3 does this properly, and there is no weakness in it worth worrying about here.
The gap between those two lists is the whole subject of this article. Encryption protects the contents of your traffic and does nothing at all for the envelope around it.
The DNS problem comes first#
Before you open a page, you look up its address. That lookup is a DNS query, and in the ordinary case it is a small, unencrypted packet sent over UDP port 53.
The query contains the name you asked for. RFC 1035 defines the message format: a DNS query carries the name being resolved in its question section. Nothing about it is confidential, because nothing about it was designed to be.
So before any TLS is involved, your ISP has already been told the name of the site. When you then connect, the same name usually appears again, inside the TLS handshake.
That repetition is not an accident of implementation. It is the reason www.wikipedia.org shows up on a network operator’s logs.
The TLS handshake has your name in it, too#
When you connect to an HTTPS site, the client sends a ClientHello to start the handshake. In the widely deployed case, that message includes a server name indication extension, the server_name extension defined in RFC 6066, which carries the hostname you are trying to reach.
The ClientHello is not encrypted. TLS 1.3 (RFC 8446) encrypts everything after the ServerHello, which improves the protocol considerably and leaves the ClientHello exactly where it was, in cleartext on the wire.
This is the single most useful fact for understanding censorship, and the same fact explains why filtering by domain name works at all: an observer on the path can read the destination hostname without breaking anything.
Encrypted Client Hello exists to close this specific gap, and it is implemented in a growing number of browsers. Deployment is still partial, and where it exists it degrades gracefully rather than failing, since servers that do not support it simply see no name, which makes the connection look more anonymous to a filter, not less.
What is left after you strip the contents#
Remove the payload and you are left with metadata, and metadata is not a consolation prize. The Tor Project states the problem plainly in its own overview: even if you encrypt the data payload of your communications, traffic analysis still reveals a great deal, because it focuses on the header, which discloses source, destination, size, and timing.
Work through it on a single evening. A list of the sites someone visited, reconstructed from DNS lookups plus destination IPs, produces a very good profile: health searches next to pharmacy sites, job boards next to a job application, one unfamiliar domain visited repeatedly at unusual hours.
This is why the IETF published RFC 7258, Pervasive Monitoring is an Attack, as an Informational RFC in 2014. No deployment is possible or intended. It is a formal statement that treating link metadata as free is a design error.
Encrypted DNS moves the observer, it does not remove one#
If DNS lookups are the problem, the obvious fix is to encrypt them. Two standards do this: DNS over TLS (RFC 7858) and DNS over HTTPS (RFC 8484). Both are real, both are widely supported, and both are worth enabling.
They also do something specific that is easy to misread. Encrypting DNS hides the lookup from the network between you and the resolver. It does not hide the lookup from the resolver.
The name you asked for still arrives at whichever server resolves it, in plaintext on that resolver’s side. In exchange you hide the lookup from your ISP and from the local network, including, usefully, from other people on the same café or campus Wi-Fi.
The gain is real. What moved is the observer, and the observer is now a single resolver rather than every router on the path.
| Observer | Plain DNS | Encrypted DNS |
|---|---|---|
| Your ISP | sees the name | sees a connection to a resolver |
| Café Wi-Fi operator | sees the name | sees a connection to a resolver |
| The resolver itself | sees the name | sees the name |
| The website | unaffected | unaffected |
Common misconceptions#
“Nobody can see anything, it’s HTTPS.” The contents, yes. The destination name and the metadata, no. The difference between the two is the entire subject of censorship resistance.
“My ISP can’t see my searches.” Searching on a search engine is one HTTPS request to one hostname. Your ISP learns the hostname. It does not learn the query terms, which are in the encrypted part, but it learns where you went.
“Incognito mode hides me.” Incognito mode changes what your browser stores and shares with other sites. It changes nothing about what leaves your router. Your ISP is upstream of the browser and does not care what the browser is doing.
“A VPN makes me invisible.” It makes the contents invisible to the local network and changes the address that destinations see. It does not remove metadata from the connection between you and the VPN server, and it introduces a party who can see both ends of your traffic. That is a trade, not a disappearance, and the next article in the path explains it in full.
“Nobody is interested in me anyway.” Possible, and irrelevant to the design question. The people who build these systems did not conclude that nobody would ever look; they concluded that the cost of being wrong is high enough to design against it.
What this means in practice#
Read your own ISP’s privacy policy before drawing conclusions from this article. Policies vary enormously, and in a number of countries operators are required to retain certain records for law enforcement. What matters for your own threat is that you know which of those rules apply to you.
The practical summary:
- Assume your ISP knows which sites you visit and when. This is a reasonable default even if the policy promises otherwise.
- Assume the contents of HTTPS traffic stay unread. This is a safe assumption, because it is a property of the protocol rather than a promise by an operator.
- Enable encrypted DNS. It moves the DNS observer from your network to a single resolver.
- Know what you are buying when you tunnel. A tunnel changes who can see the metadata: from your network to the tunnel operator.
Related#
- Privacy vs Anonymity — why hiding your destination is not the same as hiding who you are
- What Is a VPN? — what a tunnel actually changes, and what it leaves alone
- What Is Internet Censorship? — what a network does with what it can already see
Sources
- RFC 1035 — Domain Names: Implementation and Specification IETF
- RFC 6066 — TLS Extensions: Extension Definitions IETF
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 IETF
- RFC 7258 — Pervasive Monitoring Is an Attack IETF
- RFC 8484 — DNS Queries over HTTPS (DoH) IETF
- Tor: Overview The Tor Project
Last reviewed October 7, 2026. Corrections and additions are welcome.