# HTTP vs HTTPS: What TLS Adds and What It Does Not Hide

> HTTP vs HTTPS: what TLS encrypts and authenticates, what still leaks (IP, SNI, sizes), where ECH stands, HSTS, mixed content, and the SEO effect of moving to HTTPS.

Source: https://howhttpworks.com/compare/http-vs-https
Last reviewed: 2026-10-04

> **TL;DR:** HTTPS is HTTP inside a TLS connection: it encrypts the request and response, proves the server's identity with a certificate, and detects tampering. It does not hide the server's IP address, usually does not hide the hostname (SNI), and does not hide how much data moves and when. Use HTTPS everywhere, then add HSTS.

## Side By Side

| | HTTP | HTTPS |
|---|---|---|
| Transport | Plain TCP | TLS over TCP, or QUIC for HTTP/3 |
| Default port | 80 | 443 |
| Encrypted | No | Yes (path, query, headers, cookies, body) |
| Server identity verified | No | Yes, by certificate chain and hostname match |
| Tampering by network | Possible: ads, injected scripts, rewritten downloads | Detected and rejected |
| HTTP/2 in browsers | Not supported | Required in practice (browsers only do HTTP/2 over TLS) |
| HTTP/3 | Not available | Available (HTTP/3 always uses TLS 1.3) |
| Browser features | Powerful APIs such as service workers, geolocation, camera, and `Secure` cookies are restricted | Available |
| Cert cost | n/a | Free certificates exist via Let's Encrypt and others |

## What TLS Adds

1. **Confidentiality.** A passive observer on the same Wi-Fi or upstream network sees ciphertext.
2. **Integrity.** Any modification in transit breaks the record authentication, so ISPs and hotspots cannot inject content.
3. **Server authentication.** The certificate chain must validate to a trusted root and match the hostname, which is what stops a man-in-the-middle from impersonating the site. Failures surface as errors such as `NET::ERR_CERT_COMMON_NAME_INVALID`; see [ERR_CERT_COMMON_NAME_INVALID](https://howhttpworks.com/debug/err-cert-common-name-invalid).

Here is what a plain HTTP request exposes to everyone on the path:

```http
GET /account/settings?tab=billing HTTP/1.1
Host: shop.example.com
Cookie: session=7d3c1c2e...
```

On HTTPS, the observer sees only a TLS handshake to `shop.example.com` and then opaque records.

## What HTTPS Does Not Hide

| Visible to the network | Why |
|---|---|
| Destination IP address | Packets must be routed to it |
| Hostname, in most cases | The TLS ClientHello carries it in the SNI extension in cleartext, unless ECH is used |
| DNS lookups | Separate protocol; encrypted only with DoH or DoT |
| Request and response sizes, timing, direction | Traffic analysis can distinguish pages and sometimes infer what a user did |
| That you used HTTPS at all | The handshake is recognizable |

**ECH status.** Encrypted Client Hello is published as RFC 9849, a Proposed Standard on the Internet Standards Track. It encrypts the inner ClientHello, including SNI, under a public key the server publishes in a DNS HTTPS record. It requires TLS 1.3, and both the client and the server or CDN must support it, with the key discovered over DNS. It also helps most when many sites share one frontend, since the IP still reveals a single-tenant server. Check your specific browser and hosting provider before telling users it is on.

Also visible at the application layer: anything a corporate TLS-inspection proxy can decrypt. Managed devices with an installed enterprise root certificate allow that proxy to read the traffic.

## HSTS: Closing The First-Request Gap

Typing `shop.example.com` in a browser usually starts with `http://`, and a redirect to HTTPS happens only after that cleartext request, which is where an attacker on the network can strip or intercept. HSTS makes the browser remember to use HTTPS:

```http
HTTP/1.1 200 OK
Strict-Transport-Security: max-age=31536000; includeSubDomains
```

- The header only counts when received over HTTPS; browsers ignore it on HTTP responses.
- While it is active, the browser rewrites `http://` to `https://` itself and refuses to click through certificate errors for that host.
- The `preload` token plus a submission at hstspreload.org gets the domain hardcoded into browsers, which requires `max-age` of at least one year and `includeSubDomains`. Preloading is hard to undo, so confirm every subdomain serves HTTPS first.

Details and rollout order are in [Strict-Transport-Security](https://howhttpworks.com/headers/strict-transport-security).

## Mixed Content

An HTTPS page that requests `http://` subresources undermines the whole page. Browsers block active mixed content (scripts, stylesheets, iframes, fetch/XHR) and handle passive content (images, audio, video) by upgrading or warning, depending on the browser and version. A typical console message is `Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure script 'http://...'. This request has been blocked`. The fix is to change the URL in the HTML, CSS, or database content. See [Mixed content blocked](https://howhttpworks.com/debug/mixed-content-blocked) for diagnosis. `Content-Security-Policy: upgrade-insecure-requests` is a stopgap while you clean up hardcoded URLs.

Behind a TLS-terminating proxy, apps that build absolute URLs from the incoming scheme will emit `http://` links unless they trust [X-Forwarded-Proto](https://howhttpworks.com/headers/x-forwarded-proto).

## SEO, Stated Carefully

- Google has called HTTPS a lightweight ranking signal since 2014, and it is one of many. Moving to HTTPS is not a shortcut to rankings, and it is not harmful when done cleanly.
- What can hurt is a sloppy migration. Redirect every HTTP URL to its exact HTTPS equivalent with a 301 or 308 (see [301 vs 302](https://howhttpworks.com/compare/301-vs-302)), keep one canonical host, update canonicals, hreflang and sitemap URLs, and fix mixed content.
- In Search Console, HTTP and HTTPS are separate properties unless you use a Domain property.
- Redirect loops after enabling HTTPS usually come from a proxy that terminates TLS but tells the app the request was HTTP; see [ERR_TOO_MANY_REDIRECTS](https://howhttpworks.com/debug/err-too-many-redirects).

## Common Mistakes

**Believing HTTPS makes an app secure.** It protects the transport only. SQL injection, broken access control and leaked tokens are unaffected.

**Serving HTTPS but leaving port 80 open without a redirect.** Users who type the bare domain end on a dead or HTTP-only page.

**Redirecting with 302 during migration.** Use a permanent redirect so search engines consolidate on the HTTPS URL.

**Cookies without `Secure`.** A session cookie lacking `Secure` is also sent over any plain-HTTP request to the host, which defeats HTTPS. Pair `Secure` with HSTS.

**Enabling `includeSubDomains` or `preload` before checking every subdomain.** Forgotten internal hosts that only speak HTTP become unreachable.

**Assuming a padlock means the site is trustworthy.** It means the connection is encrypted to whoever holds a valid certificate for that name. Phishing sites have valid certificates too.

**Expecting a CDN to fix an expired origin certificate.** Depending on the SSL mode, edge-to-origin TLS can still fail with 525 or 526; see [525 SSL handshake failed](https://howhttpworks.com/status-codes/525).

## FAQ

### What is the difference between HTTP and HTTPS?

HTTPS is the same HTTP protocol sent through a TLS connection. TLS adds encryption (nobody on the path can read or change the request and response), server authentication through a certificate, and integrity checks. The default port changes from 80 to 443, and the URL scheme from http:// to https://.

### Does HTTPS hide which websites I visit?

Only partly. The path, query string, headers, cookies and body are encrypted, but a network observer still sees the destination IP address and, in most connections, the hostname in the TLS Server Name Indication (SNI) field. DNS queries are separate and are visible unless you use DNS over HTTPS or TLS. Encrypted Client Hello (ECH, standardized as RFC 9849) encrypts the SNI, but it needs support on both the client and the server or CDN, so do not assume it is active.

### Can my employer or ISP see what I do on HTTPS sites?

They can see which hostnames and IPs you connect to, when, and roughly how much data moves. They cannot read page contents unless a managed device has a corporate root certificate installed that lets a proxy decrypt the traffic, which is common on company laptops.

### What is HSTS and do I need it?

HTTP Strict Transport Security is a response header (Strict-Transport-Security: max-age=31536000; includeSubDomains) that tells the browser to use HTTPS for your host for the given period and refuse to continue past certificate errors. It prevents the first plain-HTTP request from being intercepted on later visits. Browsers ignore the header when it arrives over plain HTTP, so you need a working HTTPS site first.

### Does switching to HTTPS improve SEO?

Google has said since 2014 that HTTPS is a lightweight ranking signal, so do not expect a jump from it alone. The practical SEO work is in the migration: 301 redirect every HTTP URL to its HTTPS twin, update canonical URLs, sitemaps and internal links, and make sure no resources load over HTTP.

### Why does my HTTPS page say "Not secure" or show a broken padlock?

Usually mixed content: the page is HTTPS but loads a script, stylesheet, image or frame over http://. Browsers block active mixed content such as scripts and iframes and may auto-upgrade or warn about passive content. Fix the URLs in your HTML or CSS, or add a Content-Security-Policy upgrade-insecure-requests directive as a stopgap.

## References

- [MDN Web Docs: HTTP Security](https://developer.mozilla.org/en-US/docs/Web/Security)
- [MDN Web Docs: Strict-Transport-Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security)
- [MDN Web Docs: Mixed content](https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content)
- [RFC 9110: https URI Scheme (section 4.2.2)](https://www.rfc-editor.org/rfc/rfc9110#section-4.2.2)
- [RFC 8446: TLS 1.3](https://www.rfc-editor.org/rfc/rfc8446)
- [RFC 6797: HTTP Strict Transport Security](https://www.rfc-editor.org/rfc/rfc6797)
- [RFC 9849: TLS Encrypted Client Hello](https://www.rfc-editor.org/rfc/rfc9849)