HTTP vs HTTPS: What the S Actually Buys You

Somewhere along the way we taught a generation of internet users that the little padlock means a site is safe. It doesn't. It never did. The padlock means the connection between your browser and that server is encrypted, and that's a real thing worth having, but it says nothing about whether the site on the other end is a scam, a phishing page, or a perfectly legitimate business. Plenty of phishing sites have padlocks. They got them the same way everyone else does, for free, in about thirty seconds.

So let's actually unpack what the S buys you. Because the answer is more interesting than “encryption,” and the most important part is the one almost nobody talks about.

HTTP sends everything in the clear

HTTP is plain text. When your browser asks an HTTP server for a page, it sends something that looks almost exactly like this, byte for byte, across every router, switch, and wifi access point between you and the server:

GET /account/settings HTTP/1.1
Host: example.com
Cookie: session=8f3a9c1e7b2d4f60
Authorization: Basic YWxpY2U6aHVudGVyMg==
User-Agent: Mozilla/5.0

Anyone in the middle can read that. The coffee-shop wifi you're on. The ISP routing your packets. Some box in a data center three hops along the path. They see the cookie, the page you asked for, the data that comes back. And reading is the gentle version. The same position on the wire that lets you read traffic lets you change it. An attacker can rewrite the response, inject a script, swap a download link, all invisibly, because HTTP has no way to tell a tampered response from a real one.

That base64 string in the example isn't encryption, by the way. It's just an encoding. YWxpY2U6aHVudGVyMg== decodes straight back to alice:hunter2 with a one-liner anyone can run. People confuse encoding and encryption constantly, and HTTP is where that confusion gets expensive.

The S is TLS, and it does three jobs

HTTPS is just HTTP running inside a TLS tunnel. TLS (Transport Layer Security, the modern successor to the old SSL) wraps the connection before any HTTP byte gets sent. The thing to understand is that TLS isn't one feature. It's three, and they're genuinely separate properties.^[1]

• Confidentiality.The traffic is encrypted, so the people in the middle see scrambled bytes instead of your cookie and your password. This is the part everyone means when they say “HTTPS encrypts your data.”
• Integrity. Every chunk of data carries a cryptographic check. If anything on the path flips a single bit, the check fails and your browser knows the data was tampered with. No more silent script injection.
• Authentication.Before any of that, TLS proves the server is actually the one that owns the domain you typed. This is the half everyone forgets, and it's the half that makes the other two worth anything.

Here's why authentication is load-bearing. Imagine you got encryption and integrity but skipped the identity check. You'd have a perfectly encrypted, perfectly tamper-proof connection to whoever managed to sit in the middle and answer first. That's a man-in-the-middle attack, and encryption without identity does nothing to stop it. You'd be securely talking to the attacker. The whole point of the certificate is to slam that door shut.

What actually happens in the handshake

When you connect to an HTTPS site, there's a short negotiation before any page data moves. In plain English, it goes like this.^[2]

1. Your browser says hello and lists the crypto it can speak. The server picks one and sends back its certificate, which is a signed document saying “I am example.com, and here's a public key to prove it.”
2. Your browser checks that certificate (more on how in a second). If it checks out, the browser now trusts the server's public key.
3. Using that key, the two sides run some asymmetric cryptography to agree on a fresh, shared symmetric keythat only they know. An eavesdropper watching the whole exchange can't derive it.
4. From there, they switch to the symmetric key for the actual traffic. Symmetric encryption is fast, which is why the slow public-key math is only used briefly, to bootstrap the shared secret.

That's the elegant part of the design. Public-key crypto is expensive but solves the “how do two strangers agree on a secret in the open” problem. Symmetric crypto is cheap and carries the bulk of the data. TLS uses each for the job it's good at. TLS 1.3, the current version, trimmed this down to a single round trip and threw out the old weak options that made earlier versions a minefield.^[3]

Certificates and who you're really trusting

So your browser gets a certificate claiming to be example.com. Why believe it? Because the certificate is signed by a Certificate Authority, a company whose job is to verify that whoever requested the cert actually controls the domain. Your browser and operating system ship with a built-in list of CAs they trust. When a cert is signed by one of them (or by an intermediate that chains up to one of them), the signature checks out and the lock closes.^[4]That's the chain of trust. You trust your browser's root list, the root vouches for the CA, the CA vouches for the domain.

For years this was also where the “HTTPS is expensive and annoying” excuse lived. Certs cost money and you renewed them by hand. Then in 2016, Let's Encrypt launched as a free, automated, nonprofit CA, and it ate that excuse whole.^[5] Free certificates, issued and renewed by a script, no human in the loop. The web's share of encrypted page loads went from roughly half to the high nineties over the following years.^[6]The single biggest driver of HTTPS everywhere wasn't a mandate. It was making the cost zero.

What HTTPS does NOT hide

This is where the padlock oversells itself. HTTPS protects the contents of your connection, but a few things leak anyway, and it's worth being honest about them.

• Which site you're visiting. The hostname leaks in two places. DNS, the lookup that turns example.com into an IP address, has historically been unencrypted. And SNI (Server Name Indication), the field in the TLS handshake that tells a shared server which site you want, is sent before encryption kicks in. So the network can often see thatyou visited example.com, even if it can't see whatyou did there. Encrypted DNS and Encrypted Client Hello are closing these gaps, slowly, but they're not universal yet.
• Size and timing.An observer can see how much data moved and when. That metadata can be enough to fingerprint which page you loaded or whether you're streaming versus typing, without decrypting a single byte.
• Whether the site is trustworthy.Worth repeating because it's the one that bites real people. HTTPS makes the pipe secure. It does not make the thing at the end of the pipe honest.

Why plain HTTP is effectively dead

For any real site in 2026, HTTP isn't a choice you weigh anymore. The ecosystem closed ranks around HTTPS, and it did it through a combination of carrots and sticks.

• Browsers mark plain HTTP pages “Not Secure” in the address bar, and increasingly warn before loading them at all.
• The newer protocol versions assume TLS. HTTP/2 and HTTP/3 are, in practice, only spoken over encrypted connections by browsers. Want the performance, you take the encryption.
• HSTS(HTTP Strict Transport Security) lets a site tell browsers “only ever talk to me over HTTPS, and don't even try plain HTTP.” Once a browser sees that header, it upgrades every future request automatically.^[7]
• Modern browser features (service workers, geolocation, the clipboard API, and more) are gated behind a secure context, meaning they simply don't work over HTTP. Search ranking nudges the same direction.

An HSTS header is a single line, and it's the difference between “we support HTTPS” and “we refuse to do anything else”:

HTTP/2 200
strict-transport-security: max-age=63072000; includeSubDomains; preload
content-type: text/html; charset=utf-8

If you're the one building the site

The practical checklist is short now, which is the whole point of how far this got. None of this is the day-long ordeal it was a decade ago.

1. Get a certificate.It's free and automatic. Most hosts and platforms provision one for you on deploy. If you're running your own server, an ACME client renews it on a cron job and you never think about it again.
2. Redirect HTTP to HTTPS.Any request that arrives on port 80 gets a permanent redirect to the HTTPS version. Don't serve real content over plain HTTP at all.
3. Set HSTS.Add the header above once you're confident HTTPS works everywhere. It closes the gap on that very first request, the one a plain redirect leaves exposed to a downgrade attack.

That's it. The cost dropped to zero, the tooling automated itself, and the only real work left is remembering to do it. Which makes it strange how much of the public still reads the padlock as a verdict on the site rather than a fact about the connection.

So here's the take I'd leave you with. The padlock is the lowest bar there is. It says the wire is private and the server owns the domain, nothing more. And the single most valuable thing HTTPS gives you is the one nobody puts on the marketing page, the certificate check that proves you're talking to the real server and not someone wearing its face. Encryption gets all the credit. Authentication is what actually saves you.