What Does HTTPS Mean? What the Padlock Does and Doesn't Do
HTTPS is a way of sending web traffic (HTTP) protected by encryption. It protects three things: no one on the way can read the data, changes are detected, and you can check that the site is real. But the padlock only shows that "the connection is protected." It does not mean the site can be trusted.
What you'll learn
- How HTTP and HTTPS differ, and the three things HTTPS protects
- How a browser and a server that have never met share a secret key
- How certificates and certificate authorities show that a site is the real one
- What the padlock cannot protect you from
Prerequisites: none. Knowing how data travels across the internet will make it easier to read.
In everyday life
When you open a web page in a browser, the address sometimes starts with "https://". You may have been taught to "check for the padlock" before shopping or logging in online.
Yet recent versions of Chrome no longer show a padlock in the address bar. Meanwhile, people still get fooled by fake sites that do show a padlock. So what does the padlock protect, and what doesn't it? This article walks through how it works, step by step.
What HTTP is: the rules for saying "Please send this page"
To show a page, a browser sends a request to a server. A server is a computer that hands out data when asked. The set of rules that defines this conversation, "Please send this page" and "Here it is," is called HTTP.
On its own, an HTTP conversation is sent in a form anyone can read. On the internet, data is split into small chunks and relayed by many devices on its way. The devices along the way, or someone on the same Wi-Fi, could read the contents if they wanted to. "How Is Data Sent Over the Internet?" explains how the relaying works.
The "S" in HTTPS stands for Secure. The conversation itself is the same as HTTP. HTTPS wraps it in a form others cannot read before sending it. The set of rules for this wrapping is called TLS. In short, HTTPS is "HTTP protected by TLS."
TLS grew out of SSL, a method Netscape created in the 1990s. Weaknesses were found in SSL, so it fell out of use and was replaced by TLS, which was improved over several versions. The old name lives on in phrases like "SSL certificate."
The three things HTTPS protects
The risks to communication fall into three broad groups. In information security, they are called eavesdropping, tampering and spoofing (pretending to be someone else). HTTPS has a defense against each one.
| Risk | Example | HTTPS defense |
|---|---|---|
| Eavesdropping (reading) | Someone reads the password you typed | Encryption |
| Tampering (changing) | Someone changes the bank account shown for a payment | Detecting changes |
| Spoofing | A fake server pretends to be the real one | Checking with a certificate |
Encryption means using a set procedure and a "key" to turn data into a form whose meaning cannot be read. Only someone with the right key can turn it back. A key is really just a very long number (we skip the math here).
To detect changes, each piece of data that is sent comes with a short check value, calculated using the key. If even one character is changed on the way, the calculation no longer matches on the receiving side. When that happens, the connection itself is cut off.
The third point, "Is this the real site?", is checked with a certificate, explained later. First, let's see how the key for encryption gets prepared.
How do you share a key with someone you've never met?
A method that uses the same key to encrypt and to decrypt is called symmetric-key cryptography. Its math is light, so even large amounts of data can be encrypted quickly. But the browser and the server have never met. If the key were simply sent, someone on the way could read it.
The idea that solved this is public-key cryptography. It uses a matched pair of keys. One is a "public key" that anyone may see. The other is a "private key" that only its owner holds. It is designed so that working out the private key from the public key would take an unrealistic amount of time on today's computers.
The main method in today's HTTPS does not send the key itself. The browser and the server each make a throwaway secret number on their own side. This plays the role of a private key. From it, each calculates a "shareable ingredient" (which plays the role of a public key), and they send only these to each other. Each side then combines the other's ingredient with its own secret, and both end up with the same key.
Someone who sees the ingredients on the way cannot make the same key without one of the secrets. This method is called Diffie–Hellman key exchange, after the two people who came up with it. It is based on an idea published in 1976. The resulting key is then used for symmetric-key encryption. The heavy math happens only at the start, and the main traffic uses light symmetric-key encryption.
Certificates and certificate authorities: is this the real site?
How can you be sure you are talking to the real "example.com"? This is where a "certificate" comes in. A certificate is an electronic ID that pairs a site's name with that site's public key.
A certificate carries an electronic stamp from the organization that issued it. This is called a digital signature. Only the issuer's private key can make the signature, and anyone can check it with the issuer's public key. If even one character of the certificate changes, the check fails.
An organization that issues certificates is called a certificate authority (CA). Before issuing one, the CA checks that the applicant really controls the domain (the site's name). Browsers and operating systems come with a built-in list of CAs they trust. The browser follows the signatures step by step to see whether they lead to this list.
A certificate, however, is public information that anyone can see. So the server does more than show its certificate. It also proves that it holds the matching private key, by signing part of the current exchange with that key. The browser also checks that the URL it opened matches the name on the certificate and that the certificate has not expired. If anything is wrong, it shows a warning and stops the connection.
Certificates used to be mostly paid, and getting one took effort. So a CA called Let's Encrypt was created to issue certificates for free and automatically. It issued its first certificate in September 2015. It is run by ISRG, a US nonprofit. Let's Encrypt reported that about 762 million websites were using its certificates at the end of 2025.
Step by step: making the connection
Putting it all together, here is what happens when an HTTPS connection is made. The figure is a simplified version of TLS 1.3, the version that became a standard in 2018.
Once setup is done, the HTTP request ("Please send this page") and the reply flow encrypted with the new key. This setup does not start from scratch every time you open a page. There are also tricks that reuse information from an earlier connection to shorten it.
What the padlock cannot protect you from
1. Whether the site can be trusted
All the padlock shows is that "you have an encrypted connection to the site with this name." A site built to deceive can still get a certificate for a domain it registered itself. A scam that imitates a real company or similar is called phishing. It uses a fake site to trick you into entering a password or other details.
According to reports from APWG, an anti-phishing group, about 47% of phishing sites used HTTPS in October–December 2018. By July–September 2020, this had grown to about 80%. What you should check is not the padlock, but whether the domain name in the address bar is the real one. It is safer to go in through a bookmark or the official app than through a link in an email or text message.
2. Whether what arrives is safe
HTTPS only protects data on the way. It does not inspect what it carries. Viruses and other harmful programs arrive encrypted too. And what happens to your data after it arrives is up to the site's operator. HTTPS cannot prevent personal data from leaking out of a server.
3. Which sites you visit
HTTPS hides the content of the page and the part of the URL after the domain name. For example, in "example.com/account/", the "/account/" part is encrypted. Passwords you type are protected too, as are the small pieces of data that keep you logged in (cookies).
The IP address of the other side (the number of the device), however, stays visible, because it is needed for delivery. The amount and timing of traffic can be seen too. On top of that, the site's name (domain name) can often be read along the way. There are two reasons.
The first is the DNS lookup that finds the number for a name. With the traditional method, this lookup is sent without encryption.
The second is that, while setting up encryption, the browser states the name of the site it wants to reach. One server may handle many sites, so it needs this information. This field is called SNI, and until now it has been sent without encryption.
There are technologies that hide both. Methods that encrypt DNS lookups include DNS over HTTPS. ECH, which encrypts SNI, also became a standard in March 2026. But whether they are used depends on the settings of the browser, the site and the network. For now, you cannot say "with HTTPS, no one can tell which sites I visit."
Company networks have one more catch. Some companies add their own CA to the list of trusted CAs on employees' computers. They then place a device on the network that unwraps HTTPS to inspect the contents. The aim is to catch viruses and data being taken out. In this case, the company's device can read the contents even though the padlock is showing.
Browsers are changing what they show
In May 2023, Google announced it would replace the padlock in Chrome's address bar with a different icon. The new icon shows a row of sliders, a symbol for settings. Chrome has shown it since Chrome 117 in September 2023. One reason was that people misunderstood the padlock. In a 2021 Google study, only 11% of participants understood exactly what the padlock meant.
Another reason is that HTTPS has become the norm. Today it is more useful to flag pages that are not HTTPS than pages that are. Chrome labels HTTP pages "Not secure." In October 2025, Google also announced a plan to turn on a setting by default. The setting asks for confirmation before you first open a public site that does not use HTTPS. Google plans to turn it on for all users from Chrome 154 in October 2026.
Common myths
Myth: A site with a padlock is safe and trustworthy
In fact, the padlock only shows that "you have a protected connection to the site with that name." A fake site can get a certificate too. The myth comes from the days when few sites used HTTPS, when people were widely told to "check for the padlock."
Myth: With HTTPS, no one can tell which sites you visit
In fact, the other side's IP address is visible, and the site name can often be read from DNS or SNI. What is hidden is the page content, the rest of the URL and what you type. On a company network, the company's device may even be inspecting the contents.
Myth: HTTPS sends the symmetric key encrypted with the server's public key
In fact, that was one of the methods available up to TLS 1.2. TLS 1.3 removed it. When public-key techniques prepare the key, the only method left is the one where both sides exchange ingredients and build the same key. With the old method, if the server's private key were stolen later, recorded past traffic could be read as well.
That doesn't make the textbook answer wrong, though. IT certification exams and textbooks call the combination "prepare the key with public-key techniques, then send the main traffic with symmetric-key encryption" a hybrid cryptosystem. The common textbook form, "encrypt the symmetric key with the other side's public key and send it," is a correct description of its basic form. What has changed is how today's HTTPS prepares the key.
By the numbers
| Item | Number | Date and source |
|---|---|---|
| Share of pages loaded over HTTPS in Chrome | About 30–45% in 2015; about 95–99% from around 2020 (varies by OS and other factors) | Google (October 2025 announcement) |
| Websites using Let's Encrypt certificates | About 762 million | End of 2025, ISRG |
| Phishing sites using HTTPS | About 47% → about 80% | October–December 2018 → July–September 2020, APWG |
| Participants who correctly understood what the padlock meant | 11% | Google study, 2021 |
| Maximum certificate validity | 200 days → 100 days → 47 days | From March 2026, March 2027 and March 2029; CA/Browser Forum decision (2025) |
| Exchanges needed to set up TLS 1.3 | 1 round trip | TLS 1.3 standard (2018) |
Now that almost all pages load over HTTPS, the padlock only singles out the few remaining HTTP pages. That is why the habit of checking the domain name matters more than whether there is a padlock.
One reason certificate lifetimes are getting shorter is that the system for revoking problem certificates does not always work reliably. With short lifetimes, an old certificate stays usable only briefly, even if its private key is stolen or the domain changes owners.
Learn more
- Compare types of public-key cryptography in a table: RSA vs Elliptic-Curve vs Post-Quantum Cryptography (including preparing for quantum computers)
- Differences between HTTP versions: HTTP/1.1 vs HTTP/2 vs HTTP/3 (in HTTP/3, encryption is built into the protocol itself)
- Reduce the harm from fake sites: multi-factor authentication (checking who you are with something else besides a password, such as your phone)
- Test password strength with numbers: the password brute-force time calculator
- Protecting company networks: Firewall vs IDS vs IPS vs WAF, VPN (a virtual private path that encrypts all traffic, used for example to connect to a company network from outside)