HTTP vs HTTPS and the Padlock

Look at any web address and it starts with one of two words: http or https. That single extra letter is the difference between a postcard and a sealed letter. One sends your web pages out in the open for anyone along the way to read; the other wraps the same conversation so the people in between can't read or change it.

HTTP — short for HyperText Transfer Protocol — is the long-standing language browsers and websites use to ask for pages and send them back. HTTPS is that exact same language, with one addition: the whole conversation travels inside encryption. From here on we'll say HTTP for the plain version and HTTPS for the encrypted one.

Picture a postcard versus a sealed envelope. A postcard (HTTP) can be read by every courier who handles it on the way. A sealed, tamper-evident envelope (HTTPS) carries the same letter, but no courier in between can read it or quietly swap the contents. The security indicator Olivia's browser shows next to a web address is its shorthand for "this is the sealed-envelope kind." Browsers draw it differently — some show a small padlock, some a settings-style icon, and some show nothing at all for HTTPS while saving a warning for plain HTTP — but the meaning is the same.

HTTP: Readable by Anyone on the Path

When Olivia's browser asks a website for a page, the request doesn't fly straight there. It hops through a chain of in-between equipment — her home router, her internet provider, and various machines across the network — before it reaches the site. With plain HTTP, every one of those hops handles the message as plain, readable text.

That means anything she types into an HTTP page — a password, a card number, a private message — passes each of those middlemen in the clear. A party sitting on the path can read it, and can even alter the page on its way back before Olivia ever sees it. HTTP was built for sharing documents, in an early web that simply didn't worry about eavesdroppers.

HTTPS: The Same Thing, Encrypted

HTTPS doesn't replace HTTP with something exotic. It takes the very same request-and-response conversation and carries it inside an encrypted tunnel — the encryption ideas from the previous chapter, applied to the whole web connection. The website still sends pages; the browser still asks for them. Only now the contents are scrambled to everyone in between.

So the middlemen on the path are still there, still passing the traffic along — but all they see is meaningless scrambled bytes. They can't read what Olivia sent, and if they tamper with it, the change is detected rather than silently accepted. The letter is the same; the envelope around it is what changed.

What the Padlock Actually Claims

The padlock icon is a narrow, specific promise, and it pays to know exactly what it says. It claims two things: that the connection is encrypted, and that the site presented a valid certificate — a kind of digital ID confirming the connection really goes to the address shown. That's the whole claim.

Here is what the padlock does not say: that the site is honest, that the business behind it is real, or that handing it your money is wise. A scam site can set up encryption and obtain a valid certificate just like an honest one. The padlock tells Olivia how she's connected — privately — not who she should trust on the other end. We'll unpack the trust question in the next topics.

Why HTTP Is Being Retired

Because a plain HTTP connection is so easy to eavesdrop on and tamper with, browsers have steadily pushed it out. A page served over HTTP now typically shows a "Not secure" label, and browsers warn before sending anything sensitive over it. Most of the web has moved to HTTPS by default.

The reasoning is simple: there's no safe way to send a password or a card number across a connection any middleman can read. Encryption in transit went from a nice extra to the baseline expectation for nearly every site.