Web · guide

HTTP vs HTTPS: what the padlock does not say

By Alberto Gulotta · Updated 23 September 2026 · 11 min read

One letter separates them, and it stands for exactly one thing. The trouble is that people read it as standing for something larger — and the company that makes the most-used browser says so on its own help page.

So the honest translation of the two is short. HTTP carries a page between a server and your browser in the open. HTTPS carries the same page inside an encrypted connection, so that, in Google’s words, the information you send or get through the site “is private”. The S is a promise about the pipe.

What it is not is a promise about the destination — and browsers have four different things to say on the subject, only one of which is about the site itself.

Reading those four in order shows where the real judgement sits. The first three are all statements about the connection: private, not private, or something wrong with it. Only Dangerous is a statement about the site — and Google is explicit that it comes from Safe Browsing, a separate system that flags sites, rather than from anything the certificate proves.

That distinction matters more than it sounds. A certificate is not a character reference. It shows that the connection to a particular name is encrypted; it does not investigate who registered that name or what they intend to do. Which is exactly why Google’s advice on a secure page is not “relax” but “check the site name in the address bar” — the name is the part a certificate cannot vouch for on your behalf.

For a page without HTTPS, Google’s advice is plain: “Do not enter any personal information on this page. If possible, do not use the site.” Note what it does not say — it does not tell you to fix anything, because there is nothing on your side to fix.

Those two verbs are not an accident, and a source with no browser to sell breaks them into three. Mozilla’s developer documentation lists what the connection actually provides. Encryption: “the data exchanged between client and server is encrypted while in transit, so it can’t be read by any attackers”. Integrity: “an attacker can’t secretly modify data (without detection) while it is in transit between client and server”. And authentication: “client and server are each able to prove to the other party that they are the entity they claim to be”. The third is where the padlock’s reputation comes from and where it is most often misread, because MDN adds the asymmetry in the next sentence: “on the web, servers usually authenticate themselves to clients, but clients don’t usually authenticate themselves to servers”. The certificate proves the server is the name in the address bar. It proves nothing about you, and nothing about whether that name deserves your card number — which is exactly why the advice on a secure page is still to read the name.

The setting that asks first. Chrome has an option called Always use secure connections. Google describes what it does plainly: with it on, “if a site doesn’t support HTTPS, Chrome displays a ‘Your connection to this site is not secure’ warning”. So instead of quietly loading an unencrypted page, the browser stops and asks. For anybody who would rather be told than assume, that is the one switch on this page worth changing — and it changes the default from silence to a question.

There is one more thing worth knowing about what the icons do and do not tell you, and Google mentions it in passing. Selecting the symbol opens “a summary of the site’s privacy, cookies and site data, site settings, and information about the page”. The icon is a door as well as a status — and behind it is the list of what that site has been allowed to do on your machine, which is a more useful thing to read than the icon itself.

What this page will not tell you is that HTTPS makes a site trustworthy. That is the specific confusion it exists to correct, and repeating it in softer words would defeat the purpose. Encrypted and honest are two different properties, checked by two different mechanisms, and only one of them is reported by a padlock.

Nor will it tell you how to get a certificate for your own site — that belongs to the guides on hosting and domains, where the practical arrangements live.

The guides below take it three ways: what the connection protects, what it does not, and the neighbouring things a browser reports about a page.

Not covered here. It will not tell you a padlock means a site is trustworthy. Google prints a warning to keep checking the address directly beneath its own description of the secure indicator.

It will not treat the four browser states as four grades of safety. Three of them describe the connection and one describes the site, and they are not on the same scale.

And it will not tell you to work around a “not secure” warning. Google says the site owner is the one who has to fix it, and that there is nothing to enter on such a page in the meantime. What holds instead is simple: what the padlock does not say is Chrome’s own wording about its own states, and this page adds no reassurance Chrome itself withholds.