HTTPS and What It Hides
HTTPS is sometimes described as "encrypted browsing," which is true but incomplete. It encrypts the request and response payload — the URL path, the headers, the body. It does not encrypt where the traffic is going. Your ISP and any network in between can still see the destination IP and, in most current deployments, the hostname your browser is connecting to. Understanding the exact line between encrypted and visible is what lets you reason about what HTTPS does and does not protect.
The HTTPS request anatomy
A request to https://example.com/account?id=42 involves several pieces of metadata at different layers of the stack:
| Layer | Information | Visible to ISP? |
|---|---|---|
| DNS query (if plaintext) | "example.com" | Yes |
| DNS query (DoH/DoT) | "example.com" | No (if resolver isn't your ISP) |
| TCP destination IP | The server's IP | Yes, always |
| TLS SNI | "example.com" hostname | Yes (plaintext in TLS handshake) |
| TLS server certificate | Certificate including hostname | Plaintext in TLS 1.2; encrypted in TLS 1.3 |
| HTTP method, path, headers, body | "GET /account?id=42", cookies, etc. | No (encrypted) |
| Response headers and body | The page content | No (encrypted) |
| Traffic size and timing | How many bytes, when | Yes, always |
What HTTPS encrypts
Everything between the client and server after the TLS handshake completes is encrypted. That includes:
- The HTTP request line: method (GET/POST/etc.), URL path, query string.
- All request headers including Cookie, Authorization, User-Agent.
- The request body (POST data, file uploads).
- The response status code, all response headers, and the full response body.
An observer with full packet capture between client and server can confirm that an encrypted exchange occurred and measure its bytes, but cannot read any of the above without the TLS session key.
What HTTPS does not encrypt
The exposed pieces are concentrated in the connection setup:
- Destination IP address. Unavoidable — packets must route to a specific destination. Visible to every network on the path.
- TCP / UDP port. Typically 443 for HTTPS, 53 for DNS, etc. Visible always.
- SNI hostname. In current TLS 1.2 and most TLS 1.3 deployments, sent plaintext in the ClientHello. Closed by ECH; see encrypted SNI and ECH.
- Traffic patterns. Byte counts per direction, timing, packet sizes. Used for traffic analysis even on fully-encrypted streams.
What your ISP can do with what's visible
Given destination IP plus SNI, an ISP can typically determine:
- Which website you connected to (SNI is the hostname).
- When you connected, for how long, and how much data was exchanged.
- A reasonable guess at what type of activity occurred — streaming, browsing, voice call — based on traffic patterns.
What they cannot determine without breaking encryption:
- The specific page or video you watched.
- Anything you typed into a form.
- The contents of any response you received.
- Authentication credentials.
The CDN effect
When a site sits behind a CDN, every site on that CDN often shares a small pool of IP addresses. Your ISP sees the IP — it points at Cloudflare or AWS CloudFront — but cannot infer the specific site without SNI. If SNI is also encrypted (ECH), the ISP sees only "user connected to a CDN" and cannot determine which of the millions of sites on that CDN was visited. This is why CDN concentration plus ECH is, in practice, the strongest network-level privacy tool short of a VPN.
HTTPS vs VPN vs Tor
| Tool | Hides URL path | Hides destination | Hides IP from destination |
|---|---|---|---|
| HTTPS only | Yes | No | No |
| HTTPS + DoH + ECH | Yes | Mostly (CDN-sized buckets) | No |
| HTTPS + VPN | Yes | Yes (from ISP) | Partial (destination sees VPN IP) |
| HTTPS + Tor | Yes | Yes | Yes (destination sees Tor exit IP) |
Traffic analysis even on encrypted streams
Even with the best encryption stack, traffic patterns leak information. Streaming video has a characteristic burst-pause-burst signature. A Zoom call has a constant bitrate in both directions. Loading a popular site produces a recognizable size-and-timing footprint that can be matched against pre-recorded profiles. For most users this is irrelevant; for users with serious threat models, padding and timing defenses become a research problem.
The takeaway
HTTPS is necessary but not sufficient for network privacy. It closes the largest leak — request and response contents — but leaves destination metadata visible. To close the metadata side requires additional layers: encrypted DNS, ECH for SNI encryption, and ultimately a VPN or Tor for full destination concealment. Each layer is independent and each closes a specific channel; together they describe the full set of decisions about who sees what.
Frequently Asked Questions
Does HTTPS hide what websites I visit?
Partially. HTTPS encrypts the URL path, headers, and body of every request and response. But the destination IP address and the hostname in the TLS Server Name Indication (SNI) field are visible to anyone watching the network — including your ISP. So an ISP can typically see that you connected to a specific site, just not which page or what was sent/received.
What does HTTPS encrypt?
The entire HTTP request after the TLS handshake — method, path, headers, cookies, body — and the entire response — status, headers, body. Network observers cannot read or modify any of that without breaking the encryption. They can still observe that an encrypted connection exists, where it is going, and how much data flows over it.
Can my ISP see which pages I visit on a site?
No, not with HTTPS. The full URL including the path is inside the encrypted payload. The ISP sees that you connected to example.com but not /private/page. They may infer page-level activity from traffic timing and size patterns, but the URL path itself is encrypted.
What is SNI and why is it visible?
Server Name Indication is a TLS extension where the client tells the server which hostname it wants to connect to. This is necessary because multiple sites often share one IP behind a CDN or shared hosting — the server needs to know which certificate to present. SNI is sent in plaintext in the TLS handshake. Encrypted Client Hello (ECH) is the standard that fixes this, but it requires both client and server support.
Does HTTPS prevent ISP throttling?
HTTPS prevents the ISP from reading content, but it doesn't prevent the ISP from identifying which service you're using based on the destination IP and SNI hostname. ISPs can still throttle by destination — slowing all traffic to a streaming service's IP range — even when they cannot read the streams themselves.
Related Guides
How TLS Works
The protocol behind HTTPS — handshake, certificates, session keys.
Encrypted SNI / ECH
Closing the plaintext hostname channel in the TLS handshake.
Metadata vs Content Privacy
Why encryption alone leaves a lot of visibility on the table.
What Your ISP Collects
The data ISPs gather even from encrypted traffic.
More From This Section
All Privacy Guides
ISP tracking, VPN, encrypted DNS, fingerprinting, and tracking pixels.
Browser Fingerprinting and Privacy
The signals websites combine to identify your browser without cookies — fonts, canvas, WebGL, audio, screen size — and…
Browser Privacy Settings Guide
Which browser privacy settings to enable — tracking protection, fingerprint resistance, cookies, and DNS — in Chrome,…
Run a Speed Test
Measure download, upload, ping, and jitter in your browser.