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:

LayerInformationVisible to ISP?
DNS query (if plaintext)"example.com"Yes
DNS query (DoH/DoT)"example.com"No (if resolver isn't your ISP)
TCP destination IPThe server's IPYes, always
TLS SNI"example.com" hostnameYes (plaintext in TLS handshake)
TLS server certificateCertificate including hostnamePlaintext 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 bodyThe page contentNo (encrypted)
Traffic size and timingHow many bytes, whenYes, 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:

  1. Which website you connected to (SNI is the hostname).
  2. When you connected, for how long, and how much data was exchanged.
  3. A reasonable guess at what type of activity occurred — streaming, browsing, voice call — based on traffic patterns.

What they cannot determine without breaking encryption:

  1. The specific page or video you watched.
  2. Anything you typed into a form.
  3. The contents of any response you received.
  4. 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

ToolHides URL pathHides destinationHides IP from destination
HTTPS onlyYesNoNo
HTTPS + DoH + ECHYesMostly (CDN-sized buckets)No
HTTPS + VPNYesYes (from ISP)Partial (destination sees VPN IP)
HTTPS + TorYesYesYes (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

More From This Section