HTTP vs HTTPS: What TLS Actually Protects (and What It Doesn't)

The padlock icon in your browser’s address bar is one of the most widely recognized security signals on the web - and also one of the most widely misunderstood. It means exactly one specific thing, and a lot of other things people assume it means aren’t actually covered.

What TLS (the “S” in HTTPS) actually does

HTTPS is plain HTTP wrapped in TLS (Transport Layer Security) encryption. TLS provides three specific guarantees for the connection between your browser and the server: encryption (anyone intercepting the traffic - your ISP, someone on the same public WiFi, a network operator - sees scrambled data, not the actual content), integrity (the data can’t be silently modified in transit without detection), and authentication (you’re actually talking to the server that owns the domain’s certificate, not an impersonator performing a man-in-the-middle attack). That’s genuinely valuable, especially on networks you don’t control.

What it doesn’t guarantee

TLS says nothing about whether the site itself is trustworthy, honest, or safe to use. A phishing site impersonating a bank can have a perfectly valid HTTPS certificate - certificate authorities verify that you control the domain, not that your site or business is legitimate. HTTPS also doesn’t protect you from the site itself misusing your data once it arrives there, from malware hosted on an otherwise “secure” site, or from tracking and fingerprinting happening entirely within the encrypted connection. The padlock is a statement about the pipe, not about what’s flowing through it or who’s on the other end.

Where this connects to other security signals

TLS handles the connection itself, but a well-configured site layers additional protections on top of it via HTTP response headers - things like forcing HTTPS on every future visit, or preventing the page from being embedded elsewhere maliciously. Our HTTP Security Headers Checker checks for exactly these - a site can have valid HTTPS and still be missing headers that meaningfully reduce its attack surface.

A practical note on redirects

Because HTTPS has been the expected default for years now, most sites configured correctly will automatically redirect any http:// request to https:// - that’s usually the very first hop you’ll see if you trace a domain’s redirect chain. If a site doesn’t do this - if it’s still reachable over plain, unencrypted HTTP without forcing a redirect - that’s worth treating as a signal the site’s security configuration hasn’t been kept current, independent of whatever the padlock shows once you do reach the HTTPS version.