What "HTTPS" Actually Promises You (and What It Doesn't)

The padlock icon in your browser's address bar has become shorthand for "safe," which is both accurate and dangerously incomplete.

What HTTPS actually guarantees is narrower and more specific: the connection between your browser and that particular server is encrypted, and the certificate proves you're actually talking to the domain you think you're talking to, not an impostor intercepting the connection.

That's genuinely valuable — it's what stops someone on the same coffee shop WiFi from reading your password as you type it into a login form. But it says nothing at all about whether the website itself is trustworthy, honest, or safe to give your information to.

A phishing site impersonating your bank can have a perfectly valid HTTPS certificate. Certificate authorities verify that you control the domain you're requesting a certificate for — they don't verify that the domain isn't 'yourbankk-secure.com' designed to fool you at a glance.

This is why security guidance has shifted over the years from "look for the padlock" toward "look for the padlock AND check the actual domain name carefully." The padlock answers "is this connection private," not "is this the real website."

For site owners, the practical upshot is that HTTPS is necessary but not sufficient. It's table stakes at this point — most browsers actively warn visitors away from plain HTTP sites — but it's one piece of a much larger trust picture that includes everything from how you handle user data to whether your own dependencies are kept up to date.