How Does HTTPS Work? (The Padlock, and Why Nobody Can Read Your Password)

HTTPS works by scrambling everything you send to and from a website so that anyone who intercepts it in between sees only gibberish — while you and the website each hold a secret key that turns the gibberish back into real data. The padlock in your address bar is the promise that this scrambling is on. Without it (plain HTTP), your password, card number, and messages travel across the internet as readable text that anyone on the path could copy. With it, they're locked in a tunnel only the two ends can open.

The clever part is how a browser and a server agree on a shared secret while a snoop is watching the whole exchange. Here's the trick, explained simply.

Table of Contents

1. The Problem HTTPS Solves
2. The Two-Key Trick
3. The Handshake, Step by Step
4. How You Know It's Really Your Bank
5. What HTTPS Does and Doesn't Protect
6. Frequently Asked Questions

---

The Problem HTTPS Solves

When you send data over the internet, it hops through many machines — routers, your ISP, public WiFi — before reaching the site. With plain HTTP, every one of those hops can read what passes through, like mailing a postcard anyone in the postal chain can flip over and read. Type your password into an HTTP page on café WiFi and someone on that network could simply see it.

HTTPS turns the postcard into a sealed, tamper-proof envelope. Two things have to happen for that to work: the data must be encrypted (unreadable to eavesdroppers), and you must be sure you're talking to the real site, not an impostor. HTTPS does both.

The Two-Key Trick

Normal locks use one key: the same key locks and unlocks. That's a problem online — how do you give the website your key without a snoop copying it on the way?

The solution is public-key cryptography, which uses two keys that work as a pair:

• A public key that locks (encrypts) data. Anyone can have it.
• A private key that unlocks (decrypts) it. Only the website keeps this, secret.

Crucially, something locked with the public key can only be opened with the matching private key — not even with the public key that locked it. So the website can hand its public key to the entire world, and anyone can send it a locked message, but only the website can open it. The snoop sees the public key and the locked message and still can't get in.

That's the magic: you can establish a secret over a channel that's being watched.

The Handshake, Step by Step

When you visit an HTTPS site, before any real data moves, the browser and server do a quick handshake (this is the TLS protocol — the "S" in HTTPS):

1. Hello. Your browser says "I want a secure connection" and lists the encryption methods it supports.
2. Certificate. The server sends back its certificate, which contains its public key and is signed by a trusted authority (more on that next).
3. Agree on a shared secret. Using the two-key trick, the browser and server safely establish a brand-new shared key that only the two of them know — even though everything so far happened in the open.
4. Switch to the fast lock. From here, both sides use that shared secret to encrypt the actual traffic. (This faster, single-shared-key method handles the bulk data; the two-key trick was just to set it up securely.)

After the handshake, every message — your password, the pages, the card number — is scrambled with the shared key. An eavesdropper sees only noise.

How You Know It's Really Your Bank

Encryption is useless if you've encrypted a chat with an impostor. That's what the certificate is for. A trusted third party (a Certificate Authority) verifies a site owns its domain and issues it a signed certificate. Your browser trusts a built-in list of these authorities.

When the server presents its certificate, your browser checks that the signature is valid and matches the domain. If it does, you get the padlock. If it's expired, self-signed, or for the wrong domain, you get the scary "Your connection is not private" warning — your browser refusing to vouch for the other end.

What HTTPS Does and Doesn't Protect

HTTPS is essential but not magic. Know its edges:

• Protects: the contents of your traffic (passwords, messages, data) and confirms you're connected to the genuine domain.
• Doesn't hide: which site you're visiting (the domain is still visible to your network), or that a connection happened.
• Doesn't mean "safe": a scam site can have a valid padlock too. HTTPS proves the connection is encrypted and you're talking to that domain — not that the domain is trustworthy.
• Doesn't protect the ends: if your device or the server is compromised, encryption in transit won't save you.

For builders, HTTPS is the in-transit half of security. The other half is protecting data once it lands — encryption at rest, access controls, and database rules like row-level security so each user can only reach their own data. Encryption on the wire plus strict access on the server is the baseline a production app should ship with by default.

Frequently Asked Questions

How does HTTPS work in simple terms?

HTTPS encrypts the data between your browser and a website so eavesdroppers see only gibberish, and it verifies you're connected to the real site. Your browser and the server perform a "handshake" to agree on a secret key, then use that key to scramble all the traffic.

What does the padlock icon actually mean?

It means your connection to that domain is encrypted and the site presented a valid certificate proving it controls that domain. It does not mean the website is trustworthy — scam sites can have padlocks too. It only guarantees a private connection to that specific domain.

What's the difference between HTTP and HTTPS?

HTTP sends data as readable text that anyone on the network path can intercept and read. HTTPS encrypts that data so only you and the website can read it, and it authenticates the site's identity. Never enter passwords or payment details on a plain HTTP page.

How do a browser and server share a secret key without it being stolen?

They use public-key cryptography: the server has a public key (which anyone can use to lock data) and a private key (which only it can use to unlock). Because only the private key can open what the public key locked, they can safely establish a shared secret even while someone is watching the exchange.

Is HTTPS enough to keep me safe online?

It's necessary but not sufficient. HTTPS protects data in transit and confirms the domain, but it doesn't tell you whether a site is honest, hide which sites you visit, or protect you if your device or the server is compromised. Treat the padlock as "private connection," not "trustworthy site."