To understand how HTTPS works, start with what it actually does: it takes ordinary web traffic and wraps it in a layer that encrypts the data, verifies you're really talking to the site you intended, and detects any tampering along the way. This guide walks through the TLS handshake step by step, the two kinds of encryption it cleverly combines, how certificates and the chain of trust prove a site's identity, and—just as important—what HTTPS doesn't protect. By the end, that little padlock will mean something specific to you rather than a vague "this is safe."
What HTTPS is and what it protects
HTTP, the Hypertext Transfer Protocol, is the language browsers and servers use to exchange web pages. On its own it's plaintext: anyone between you and the server—someone on the same coffee-shop Wi-Fi, your network provider, a compromised router—can read and even alter it. HTTPS is simply HTTP running inside an encrypted channel provided by TLS (Transport Layer Security), the modern successor to the older SSL.
That channel delivers three distinct guarantees, and it's worth separating them:
- Confidentiality — the data is encrypted, so eavesdroppers see only scrambled bytes.
- Integrity — any tampering with the data in transit is detected and rejected.
- Authentication — you can verify the server is genuinely the one that owns the domain, not an impostor.
This is exactly why HTTPS matters on untrusted networks. On open or shared Wi-Fi—including a home Wi-Fi 7 network with guests on it—HTTPS keeps your login and payment details private even if the network itself can't be trusted. It's also why effectively all modern web traffic, from banking to video that streaming services deliver, runs over HTTPS today.
One clarification up front, because it's widely misunderstood: HTTPS encrypts the content of your connection, but it doesn't hide which site you're visiting. We'll return to that gap in the final section.
The two kinds of encryption HTTPS combines
HTTPS leans on two families of cryptography, and the trick is that it uses each for what it's good at.
Asymmetric encryption (also called public-key cryptography) uses a mathematically linked pair of keys: a public key anyone can have and a private key the server keeps secret. Data scrambled with one can only be unscrambled with the other. This solves a hard problem—two strangers establishing a secret over a channel anyone can watch—but it's computationally expensive and slow for bulk data.
Symmetric encryption uses a single shared key that both sides use to encrypt and decrypt. It's far faster, but it has a chicken-and-egg problem: how do both parties get the same secret key without an eavesdropper grabbing it in transit?
HTTPS uses each to cover the other's weakness. It uses asymmetric methods during setup to securely agree on a fresh symmetric key, then switches to fast symmetric encryption (typically AES or ChaCha20) for the actual conversation. The asymmetric part does the introductions; the symmetric part does the talking.
The TLS handshake, step by step
Before any web page moves, the browser and server run a TLS handshake to authenticate the server and agree on that shared symmetric key. Here's the sequence with the current standard, TLS 1.3, which streamlined it to a single round trip:
- ClientHello. Your browser opens the conversation, sending the TLS versions and cipher suites (encryption algorithms) it supports, a random value, and—new in TLS 1.3—its half of a key exchange (an ephemeral public key).
- ServerHello and certificate. The server picks a cipher, sends its own random value and key-exchange half, and presents its digital certificate—the credential proving its identity. It also sends a signature created with its private key, demonstrating it actually holds the key the certificate vouches for.
- Key derivation. Using the two exchanged key-exchange halves, both sides independently compute the same shared secret without ever transmitting it—a technique called Diffie-Hellman key exchange. Because the keys are ephemeral (freshly generated per session), this provides forward secrecy: even if the server's private key leaks later, past sessions can't be decrypted.
- Verification. Your browser validates the certificate (the next section explains how) and confirms the server's signature. If anything fails, you get a security warning instead of a page.
- Encrypted data flows. Both sides switch to the agreed symmetric key, and the real HTTP request and response—now fully encrypted—begin.
TLS 1.3 completes this in one round trip, noticeably faster than the two round trips of the older TLS 1.2, and it supports near-instant resumption for repeat visits. This handshake runs after your browser has already resolved the site's address; if you're fuzzy on that earlier step, our explainer on how DNS turns a name into an address covers it.
Certificates and the chain of trust
A certificate is only useful if you can trust it. Anyone can generate a key pair and claim to be yourbank.com—so how does your browser know a certificate is legitimate? Through a chain of trust anchored in Certificate Authorities (CAs).
A CA is an organization browsers and operating systems have agreed to trust. Your device ships with a built-in trust store of root CA certificates. When a site presents its certificate, it's actually a chain: the site's own leaf certificate is signed by an intermediate CA certificate, which is signed by a root certificate already in your trust store. Your browser walks this chain, verifying each signature, and trusts the leaf only if the chain leads back to a trusted root. It also checks that the certificate's domain matches the site, that it hasn't expired, and that it hasn't been revoked.
Certificates come in validation levels. Domain Validation (DV) simply proves control of the domain and is what free, automated authorities like Let's Encrypt issue—this automation is a big reason HTTPS went from rare to nearly universal. Organization Validation (OV) and Extended Validation (EV) involve checks on the legal entity; EV once produced a green address bar, though browsers have since de-emphasized that distinction.
There's a neat link back to DNS here: a domain owner can publish a CAA record in DNS specifying exactly which CAs are allowed to issue certificates for that domain, closing off a class of mis-issuance attacks. And in practice, the TLS handshake for big sites is often performed not by an origin server but by a content delivery network terminating the connection at a nearby edge, which is part of how large sites stay fast and secure at once.
TLS versions, pitfalls, and what HTTPS doesn't protect
Not all HTTPS is equal, and the padlock hides some important nuance.
On versions: TLS 1.3 (standardized in 2018) is the current best practice—faster and with weak, legacy options removed. TLS 1.2 remains widely supported and secure when configured well. The older TLS 1.0 and 1.1 were formally deprecated in 2021 and should not be used. A related safeguard is HSTS (HTTP Strict Transport Security), a setting that tells browsers to only ever connect to a site over HTTPS, preventing downgrade attacks.
A few common pitfalls and misconceptions:
- The padlock means "encrypted," not "trustworthy." A phishing site can obtain a valid DV certificate and show a padlock. HTTPS proves you have a private, authenticated channel to that domain—it says nothing about whether the domain itself is honest. Don't read the padlock as a safety endorsement.
- Mixed content weakens a page. An HTTPS page that loads images or scripts over plain HTTP undermines its own security; modern browsers block or warn about this.
- Certificate warnings deserve respect. Expired, self-signed, or wrong-domain certificate errors are exactly the signal HTTPS exists to give. Clicking through on a sensitive site defeats the protection.
Finally, the crucial limit. HTTPS encrypts the URL path, headers, cookies, and content—but it does not hide which site you're visiting. The DNS lookup that precedes the connection, and the SNI (Server Name Indication) field your browser sends in the handshake to tell the server which site it wants, both typically reveal the domain to anyone watching the network. So your provider or network operator can often see that you visited example.com, just not what you did there. Closing that metadata gap is one reason people use a VPN to tunnel and hide their traffic, alongside encrypted DNS. HTTPS is essential, but it's one layer, not a cloak of total privacy.
Frequently asked questions
What's the difference between HTTP and HTTPS? HTTP sends data as plaintext that anyone on the network path can read or alter. HTTPS runs that same HTTP inside a TLS-encrypted channel, adding confidentiality, integrity, and authentication. The "S" stands for secure, and it's now the default for essentially all serious websites.
What is the difference between SSL and TLS? They're the same idea at different ages. SSL was the original protocol; TLS is its modern, more secure successor. People still say "SSL certificate" out of habit, but every secure site today uses TLS—currently TLS 1.2 or the faster, leaner TLS 1.3.
Does the padlock icon mean a website is safe? No. The padlock means your connection to that site is encrypted and the site proved control of its domain. It does not mean the site is honest or trustworthy—scam and phishing sites can have valid certificates too. Judge the site itself separately.
Can someone see what I'm doing on an HTTPS site? The content is hidden, but the destination usually isn't. Through the DNS lookup and the unencrypted SNI field in the handshake, a network observer can often tell which domain you connected to, even though they can't read the pages or data exchanged.
Why do I sometimes get a certificate error? Because the browser's validation failed—the certificate may be expired, self-signed, issued for a different domain, or from an untrusted authority. These warnings are the authentication guarantee working as intended; treat them seriously, especially on sites handling sensitive information.
The takeaway
Now that you know how HTTPS works, the padlock carries a precise meaning: your connection to that specific domain is encrypted, intact, and authenticated by a chain of trust rooted in your browser—established in a fast TLS 1.3 handshake that swaps asymmetric setup for symmetric speed. The practical next step is to read certificate warnings as real signals rather than annoyances, and to remember that HTTPS secures the channel but doesn't hide which sites you visit. It's the bedrock of web security, and seeing exactly what it does and doesn't cover makes you a sharper judge of what "secure" really means online.