How HTTPS Works
Every time you log in over café Wi-Fi, your data crosses a network full of strangers — the router, the coffee shop's ISP, and anyone else on the same connection. Yet your password still arrives at the right server, unread by anyone in between. That everyday magic has a name: HTTPS. Here's how it actually works.
The problem: the network is public
The internet was built to move packets from A to B, not to keep them secret. A plain HTTP request travels as readable text, so every machine that relays it can see — and even change — what's inside. On an open network that's a real risk: a snoop can read your messages, and a meddler can rewrite the page you asked for. HTTPS exists to close both holes. It gives you privacy (nobody in the middle can read your traffic) and integrity (nobody can tamper with it undetected).
Step one: prove who you're talking to
Before any secrets are shared, your browser needs to know the server is really who it claims to be. The server presents a certificate — a digital ID signed by a trusted Certificate Authority (CA). Your browser already carries a list of CAs it trusts, so it can check the signature the way you might check a passport's watermark. If the certificate is valid and matches the site's name, the browser proceeds. If it's expired, self-signed, or for the wrong domain, you get the scary warning page. This step stops an attacker from simply impersonating your bank.
Step two: agree on a secret
Now both sides need a shared key to scramble their messages — but they're shouting across a public wire, so how do they agree on a secret without anyone overhearing it? This is the clever part. Using public-key cryptography, the browser and server perform a key exchange where each side combines its own private value with the other's public value. The math works out so both compute the same shared key, yet an eavesdropper who saw every message pass by cannot reconstruct it. Modern HTTPS also makes this key temporary, so even if a server's long-term key leaks later, past conversations stay locked.
Step three: talk in code
With a shared secret in hand, the two sides switch to symmetric encryption — fast, two-way scrambling that uses that single key. From here on, every request and response is encrypted before it leaves and decrypted only on arrival. To anyone watching the network, your login looks like meaningless noise. Symmetric encryption is used for the actual conversation because it's much faster than the public-key math; the slow key exchange happens just once, up front, to bootstrap it.
Why the padlock matters
The little padlock in your address bar means all three steps succeeded: the server proved its identity, both sides secretly agreed on a key, and the traffic is now encrypted. It does not promise the site itself is honest — a scam site can have a valid certificate too — only that your connection to it is private and untampered. That distinction is worth remembering: HTTPS secures the pipe, not the intentions of whoever's on the other end.
The takeaway
HTTPS turns a hostile, public network into a private channel using a simple sequence: verify identity, exchange a secret safely, then encrypt everything. It runs in milliseconds, on nearly every site you visit, and you almost never notice it — which is exactly the point. Good security is the kind you never have to think about.
This explainer was made with LineLapse — type a topic, get a hand-drawn video. Make your own →