That little padlock in your browser’s address bar represents one of the most important security systems on the internet. But how does HTTPS work, exactly? HTTPS, or Hypertext Transfer Protocol Secure, wraps ordinary web traffic in TLS encryption so nobody between you and a website can read or tamper with what you exchange. Every login, payment, and private message you send depends on it. This beginner-friendly guide explains how HTTPS works step by step: the TLS handshake, certificates, symmetric versus asymmetric encryption, and what to do when your browser warns you that a site is not secure.
In This Guide
- HTTPS vs HTTP: What Changes?
- The Three Ingredients of HTTPS
- How the TLS Handshake Works, Step by Step
- Certificates: How Your Browser Trusts a Website
- Symmetric vs Asymmetric Encryption in HTTPS
- Inspect HTTPS Yourself With One Command
- Browser Warnings: What They Mean and What to Do
- Frequently Asked Questions
- Key Takeaways
HTTPS vs HTTP: What Changes?
HTTP is the language browsers and servers use to exchange web pages, but plain HTTP sends everything as readable text. On an open Wi-Fi network, anyone with basic tools can watch which pages you visit, read form submissions, and even inject fake content into pages. That was acceptable in the early web, when most browsing was public information, but it is catastrophic for banking, email, and shopping.
HTTPS is HTTP with a TLS (Transport Layer Security) encryption layer underneath. Before any page content moves, your browser and the server run a handshake that authenticates the server and negotiates secret encryption keys. After that, everything, the URL path, headers, form data, page content, is encrypted. Eavesdroppers see only that you connected to a domain, not what you did there. Today over 95% of web traffic uses HTTPS, and browsers actively shame sites that do not.
The Three Ingredients of HTTPS
Understanding how HTTPS works is easier when you separate its three jobs:
1. Encryption: Nobody Can Read the Traffic
TLS encrypts the conversation with strong symmetric ciphers like AES-256 or ChaCha20. Without the session key, intercepted traffic is meaningless noise.
2. Authentication: You Are Talking to the Real Site
Encryption alone is not enough; you could be encrypting a conversation with an impostor. Digital certificates, verified against trusted certificate authorities, prove the server really owns the domain name in the address bar.
3. Integrity: Nobody Can Silently Alter the Traffic
Every TLS record carries a message authentication code. If a middleman flips even one bit, the tampering is detected and the connection drops. This defeats injection attacks where an ISP or attacker inserts ads or malware into pages.
How the TLS Handshake Works, Step by Step
The TLS handshake is the choreographed introduction at the start of every HTTPS connection. Modern TLS 1.3 completes it in a single round trip, but the logic is the same in all versions:
Step 1: ClientHello
Your browser sends a hello listing the TLS versions and cipher suites it supports, plus a random number and, in TLS 1.3, an early key-share guess to save a round trip.
Step 2: ServerHello and Certificate
The server picks a TLS version and cipher suite, sends its own random number and key share, and presents its certificate chain: its own certificate plus intermediate certificates linking up to a trusted root.
Step 3: Verification
Your browser checks the certificate: Is it signed by a trusted certificate authority? Has it expired? Does the domain name match the address bar? Is it revoked? If anything fails, you get a warning page instead of the site.
Step 4: Key Exchange and Finished
Using the exchanged key shares, both sides independently compute the same session keys without ever transmitting them. Each side then sends an encrypted “finished” message proving the handshake was not tampered with.
Step 5: Encrypted Application Data
From here on, HTTP requests and responses flow inside the encrypted tunnel. The expensive asymmetric cryptography is over; the bulk transfer uses fast symmetric encryption. Session resumption lets repeat visits skip most of this work.
Certificates: How Your Browser Trusts a Website
A TLS certificate is a small file binding a public key to a domain name, signed by a certificate authority (CA) your browser already trusts. Your operating system and browser ship with a store of about a hundred trusted root CAs.
Domain Validation, the Common Case
Most certificates are domain-validated (DV): the CA only verifies that the requester controls the domain, usually by checking a DNS record or an email to the domain owner. Free automated CAs like Let’s Encrypt made DV certificates universal, which is why the padlock no longer means a site is trustworthy, only that the connection is encrypted and the domain is verified.
Chain of Trust
Root CAs rarely sign site certificates directly. They sign intermediate CAs, which sign the site’s certificate, forming a chain your browser walks up to a trusted root. If any link is missing or expired, verification fails.
Revocation
If a certificate’s private key is stolen, the CA revokes it by publishing to revocation lists or OCSP responders. Browsers check these, though in practice revocation checking is imperfect, which is why short-lived certificates (90 days, auto-renewed) are now the norm.
Symmetric vs Asymmetric Encryption in HTTPS
How does HTTPS work so fast if public-key cryptography is slow? It uses each type of encryption for what it is good at.
| Asymmetric (Public-Key) | Symmetric | |||
|---|---|---|---|---|
| Keys | Public key encrypts, private key decrypts | One shared secret key | ||
| Speed | Slow, computationally heavy | Very fast (hardware-accelerated AES) | ||
| Used in HTTPS for | Authentication and negotiating session keys | Encrypting all page traffic | ||
| Key exchange problem | None: public keys can be shared openly | Solved by the handshake above | ||
This hybrid design is the standard trick of modern cryptography: asymmetric crypto solves the key-distribution problem once per connection, then symmetric crypto does the heavy lifting. Forward secrecy, standard in TLS 1.3, goes further: session keys are derived from ephemeral key pairs discarded after use, so even if a server’s private key is stolen later, past traffic stays unreadable. The MDN glossary entry on HTTPS and the MDN glossary entry on TLS are good authoritative references for these terms.
Inspect HTTPS Yourself With One Command
You can watch how HTTPS works in practice using OpenSSL, which is preinstalled on macOS and most Linux systems. This command opens a TLS connection and shows the certificate chain, negotiated protocol, and cipher:
openssl s_client -connect example.com:443 -tls1_3 < /dev/null
Look for the Certificate chain section (the chain of trust), the Protocol : TLSv1.3 line, and the Cipher line showing the negotiated symmetric cipher. Press Ctrl+C to exit. In your browser, clicking the padlock icon and choosing “Connection is secure” then “Certificate is valid” shows the same information in a friendlier form, including the issuing CA and expiry date. Try it on your bank’s site and on a plain HTTP site to feel the difference.
Browser Warnings: What They Mean and What to Do
Browsers interrupt you with full-page warnings when certificate verification fails. Take them seriously; they are the authentication half of HTTPS doing its job.
“Your connection is not private” (Expired or Invalid Certificate)
The certificate expired, the domain name does not match, or the chain is broken. Do not enter credentials. If it is a site you trust, the owner needs to renew the certificate; notify them through another channel.
Mixed Content Warnings
An HTTPS page that loads images or scripts over plain HTTP is vulnerable: attackers can tamper with the insecure parts. Browsers block the dangerous kinds automatically. Site owners should serve everything over HTTPS; there is no legitimate reason for mixed content in 2026.
HSTS: Forcing HTTPS
Sites can send a Strict-Transport-Security header telling browsers to never use plain HTTP for that domain again, defeating downgrade attacks. Major sites preload this into browsers themselves. It is a one-line server header and every serious site should set it.
Note the limits: HTTPS encrypts traffic in transit, but the site itself still sees everything you send, and a padlock says nothing about whether a business is honest. Phishing sites use HTTPS too, which is why checking the actual domain name matters more than the padlock. For more on how attackers abuse trust signals, see our guide to how QR codes work, including the quishing scams that hide behind innocent-looking codes.
Frequently Asked Questions
What does the S in HTTPS stand for?
Secure. It means the HTTP traffic is encrypted with TLS, providing encryption, authentication, and integrity for the connection.
Is HTTPS the same as TLS?
Not exactly. HTTPS is HTTP carried over a TLS-encrypted connection. TLS is the security layer; HTTPS is the combination. (TLS replaced the older SSL, though people still say “SSL certificate” out of habit.)
Does HTTPS make a website trustworthy?
No. HTTPS guarantees you are talking privately to the domain in the address bar, but a phishing site can get a valid certificate in minutes. Always verify the domain name itself.
Why do some sites still use HTTP?
Usually neglect: old embedded devices, misconfigured servers, or internal tools nobody updated. There is no cost barrier anymore, since certificates are free, so plain HTTP on a public site in 2026 is a red flag.
Can my ISP see what I do on HTTPS sites?
Your ISP can see which domains you connect to (via DNS and the TLS handshake’s SNI field), but not the specific pages, searches, or form data. Encrypted DNS and VPNs can hide even the domain.
What port does HTTPS use?
Port 443 by default, versus port 80 for plain HTTP. Firewalls and servers treat them as separate services.
Key Takeaways
- HTTPS is HTTP encrypted with TLS, adding encryption, server authentication, and tamper detection to web traffic.
- The TLS handshake authenticates the server via certificates and negotiates secret session keys in about one round trip.
- Certificates bind a domain to a public key through a chain of trust ending at root CAs in your browser.
- Hybrid cryptography is used: slow asymmetric crypto sets up the connection, fast symmetric crypto carries the data.
- Forward secrecy in TLS 1.3 protects past traffic even if a server’s key is later stolen.
- A padlock means a private connection to that domain, not that the site itself is honest; always check the domain name.
Conclusion
So how does HTTPS work, in short? Your browser and the server perform a TLS handshake that verifies the site’s certificate and negotiates secret keys, then every request and response travels inside an encrypted tunnel that eavesdroppers cannot read and middlemen cannot alter. Three ingredients, encryption, authentication, and integrity, turn the open postcard of HTTP into a sealed envelope. The next time you see that padlock, you will know it represents a real cryptographic conversation, and you will also know its limits: it protects the journey, not the destination. Pair this knowledge with our beginner guide to what an API is to understand what actually travels inside those encrypted requests your apps make all day.