Right now, your browser is checking a tiny padlock icon. If it’s there, your connection is encrypted. If it’s not, anyone on the same Wi-Fi can read every word you type — including passwords.
That padlock is the difference between HTTP and HTTPS. Let’s break down what’s really happening.
Introduction
- What HTTP and HTTPS actually do
- How TLS encryption works (simplified)
- Why HTTPS is now mandatory, not optional
- How to check if a site is secure
HTTP is like sending a postcard.
- Everyone who handles it (mailman, post office, nosy neighbor) can read the message.
- The address is visible. The content is visible. Nothing is hidden.
HTTPS is like sending a sealed, locked envelope.
- The address is visible (so it can be routed), but the content is encrypted.
- Only the sender and receiver have the key to open it.
- If someone intercepts it, they see gibberish.
HTTP vs HTTPS: The Visual Difference
How HTTP Works
HTTP (HyperText Transfer Protocol) is the foundation of the web. When you type a URL, your browser sends an HTTP request and the server sends back an HTTP response.
The problem? Everything is in plain text.
| What’s Exposed | Risk |
|---|---|
| URLs visited | Your browsing history is visible |
| Form data | Passwords, credit cards, messages |
| Cookies | Session tokens can be stolen |
| API calls | Business data leaks |
- ❌ Enter passwords
- ❌ Submit credit card numbers
- ❌ Send private messages
- ❌ Use public Wi-Fi without checking for HTTPS
How HTTPS Works
HTTPS = HTTP + TLS (Transport Layer Security).
TLS wraps every HTTP request in an encrypted layer. Here’s the simplified process:
The TLS 1.3 Handshake (Step by Step)
| Step | Who Acts | What Happens |
|---|---|---|
| 1. Client Hello | Browser | ”Here are the TLS versions and cipher suites I support” |
| 2. Server Hello | Server | ”I’ll use TLS 1.3 + AES-256-GCM. Here’s my SSL certificate.” |
| 3. Certificate Validation | Browser | Verifies the cert against trusted Certificate Authorities |
| 4. Key Exchange (ECDHE) | Both | Both sides compute the same session key without transmitting it |
| 5. Finished | Both | Both send a “Finished” message encrypted with the session key |
| 6. Encrypted HTTP | Both | All HTTP traffic now flows through AES-256 symmetric encryption |
TLS 1.2 required 2 round-trips (the full handshake) before the first byte of data. TLS 1.3 reduces this to 1 round-trip. For a user 100ms away from a server, this saves 100ms on every new connection. With 0-RTT resumption, repeat visitors see zero TLS overhead.
Inspecting HTTPS in the Real World
View the full TLS handshake and HTTP headers
- •-v shows the TLS version, cipher suite, and certificate details
- •Look for 'SSL connection using TLSv1.3'
Inspect a server's SSL/TLS certificate directly
openssl s_client -connect [host]:[port]openssl s_client -connect shekharit.com:443- •Shows certificate chain, expiry date, and cipher suite
- •Press Ctrl+C to exit
The SSL Certificate: Your Digital ID
An SSL/TLS certificate is a digital document that proves a website is who it claims to be. It contains:
| Field | Purpose |
|---|---|
| Subject | The domain name (e.g., shekharit.com) |
| Issuer | The Certificate Authority (e.g., Let’s Encrypt) |
| Valid From / To | Expiry dates (usually 90 days for Let’s Encrypt) |
| Public Key | Used during the TLS handshake |
| Signature | Cryptographic proof from the issuer |
Who Issues Certificates?
Certificate Authorities (CAs) are trusted organizations that verify domain ownership:
| CA | Cost | Used By |
|---|---|---|
| Let’s Encrypt | Free | Most websites, blogs, small businesses |
| DigiCert | $$$$ | Banks, governments, enterprises |
| Cloudflare | Free (through their CDN) | Cloudflare-proxied sites |
Thanks to Let’s Encrypt, HTTPS is now free for everyone. There is no excuse for any website to still use HTTP in 2026.
HTTP vs HTTPS: Feature Comparison
| Feature | HTTP | HTTPS |
|---|---|---|
| Port | 80 | 443 |
| Encryption | ❌ None | ✅ TLS |
| Data Integrity | ❌ Can be modified in transit | ✅ Tamper-proof |
| Authentication | ❌ No proof of identity | ✅ Certificate verifies server |
| SEO Ranking | ❌ Google penalises HTTP | ✅ Ranking boost |
| Browser Warning | ⚠️ “Not Secure” badge | ✅ Padlock icon |
| Protocol Version | HTTP/1.1 only | HTTP/2 and HTTP/3 available |
| Speed | Slower (HTTP/1.1) | Faster (multiplexing, 0-RTT) |
HTTPS is Faster Than HTTP — Not Just More Secure
A common myth: “HTTPS adds overhead so it’s slower.” In 2026, the opposite is true:
| Protocol | Requires TLS | Key Features | Speed Impact |
|---|---|---|---|
| HTTP/1.1 | ❌ No | One request per connection | Slowest |
| HTTP/2 | ✅ Yes | Multiplexing, header compression, server push | 2-3x faster |
| HTTP/3 | ✅ Yes | Runs over QUIC (UDP), eliminates TCP head-of-line blocking | Fastest |
HTTP/2 and HTTP/3 are only available over HTTPS. Switching to HTTPS doesn’t slow you down — it unlocks faster protocols.
Check which HTTP version a server uses
- •Look for 'HTTP/2' in the response
- •Use --http3 flag to test HTTP/3 support
Common Myths Debunked
Myth: “HTTPS is slow.” Reality: TLS 1.3 adds less than 1ms of latency. HTTP/2 and HTTP/3 (which require HTTPS) are actually faster than HTTP/1.1.
Myth: “I don’t need HTTPS — my site has no login.” Reality: Google Chrome marks ALL HTTP sites as “Not Secure.” Your visitors will leave.
Myth: “The padlock means the site is safe.” Reality: The padlock means the connection is encrypted. A phishing site can still have HTTPS. Always check the domain name.
How to Check if a Site is Secure
In the Browser
- Look for the padlock icon in the address bar
- Click the padlock → View Certificate
- Check: Is the domain correct? Is it expired?
From the Terminal
Check if a site enforces HTTPS with HSTS header
- •HSTS (HTTP Strict Transport Security) forces browsers to always use HTTPS
- •Look for: Strict-Transport-Security header
If you’re new to HTTPS, this is a great stopping point. The Key Takeaways below cover everything you need day-to-day.
The sections below (Mixed Content, CSP, Certificate Transparency) are for developers building websites who need to implement HTTPS correctly. Bookmark and return when you’re ready.
Mixed Content: When HTTPS Loads HTTP Resources
Mixed content occurs when an HTTPS page loads some resources (images, scripts, CSS) over HTTP. This is a security risk because:
- Active Mixed Content (scripts, iframes): Browsers block this entirely — a malicious HTTP script could hijack the HTTPS page
- Passive Mixed Content (images, video): Browsers allow but warn — an attacker could swap the image
How to detect mixed content:
Check if a site has a Content Security Policy that blocks mixed content
- •In Chrome: Open DevTools > Console. Mixed content errors appear as warnings
- •CSP header with 'upgrade-insecure-requests' auto-upgrades HTTP resources to HTTPS
How to fix: Change all http:// resource URLs to https:// in your HTML/CSS. Add this header to auto-upgrade any remaining HTTP resources:
Content-Security-Policy: upgrade-insecure-requests
Getting HTTPS for Your Own Site
Understanding HTTPS is great — enabling it is what matters. Here are your options:
Option 1: Let’s Encrypt + Certbot (Free, Self-Managed)
Install Certbot — the free Let's Encrypt certificate agent
- •After install, run: sudo certbot --nginx -d yourdomain.com
- •Certbot auto-renews certs before they expire (90-day certs)
- •Supports Apache: use python3-certbot-apache instead
Option 2: Cloudflare (Free, One-Click)
If your domain uses Cloudflare’s DNS, enable HTTPS in one minute:
- Log into Cloudflare Dashboard
- Go to SSL/TLS → set to Full (Strict)
- Done — Cloudflare provisions and renews the cert automatically
Option 3: Your Hosting Provider
Most modern hosts (Netlify, Vercel, Railway, Render) provision free TLS automatically on deploy. No action needed.
Every TLS certificate issued is recorded in a public Certificate Transparency (CT) Log — a global, append-only ledger. This means anyone can check what certificates have been issued for a domain, and browsers reject certificates that aren’t in the CT log. It’s how security researchers detect fraudulent or mis-issued certs. Check your domain at crt.sh.
Troubleshooting HTTPS Issues
| Problem | Explanation | Solution |
|---|---|---|
| ”Your connection is not private” | Certificate expired or invalid | Contact site owner; or check your system clock |
| Mixed Content warnings | Page loads HTTP resources inside HTTPS | Fix all resource URLs to use https:// |
| Certificate name mismatch | Cert is for www.example.com but you visited example.com | Add both domains to the certificate |
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Server uses outdated TLS version | Upgrade server to TLS 1.2 or 1.3 |
Quiz: Test Your Knowledge
Test Your Knowledge
Take a quick 5-question quiz to check your understanding.
Key Takeaways
- HTTP = Postcard (everyone can read), HTTPS = Sealed Envelope (encrypted).
- TLS encrypts the connection using a handshake + shared secret key.
- Certificates prove the server’s identity. Let’s Encrypt makes them free.
- HTTPS is mandatory — Google penalizes HTTP, and browsers show “Not Secure” warnings.
- The padlock ≠ safe site — it only means the connection is encrypted. Always verify the domain.
Now that you understand HTTPS, go deeper:
- What is a Firewall? (Network security)
- What is a VPN? (Encrypted tunnels)
- Password Security (The first line of defense)
Found this helpful? Explore more in the Security Hub!