You've seen it thousands of times — that small padlock in the browser's address bar sitting quietly next to a URL. Most people glance at it, feel vaguely reassured, and move on. But what does that symbol actually mean? What happens in the fraction of a second between you typing a URL and your browser deciding to show you a padlock instead of a warning? And why do developers still argue that their simple portfolio site "doesn't need HTTPS"? Spoiler: they're wrong, and this article explains exactly why — without making you sit through a networking degree first.
HTTP vs HTTPS: What the S Actually Stands For
HTTP stands for HyperText Transfer Protocol. It is the language your browser uses to ask a web server for a page and receive one back. Think of it like sending a postcard: the message is out in the open, readable by anyone who handles it along the way. Your internet provider, someone on the same coffee-shop Wi-Fi, a misconfigured router in a data centre — all of them can read every word.
HTTPS adds an S for Secure. Specifically, it wraps HTTP inside a protocol called TLS — Transport Layer Security. TLS turns that postcard into a sealed, tamper-evident envelope. The contents are scrambled so only the intended recipient can unscramble them, and any attempt to tamper with the letter in transit leaves visible marks. Same postal route. Completely different level of privacy.
TLS replaced its predecessor SSL (Secure Sockets Layer) years ago, but "SSL" stuck around as a colloquial term the way "Band-Aid" stuck around for plasters. When someone sells you an "SSL certificate," they almost certainly mean a TLS certificate. The underlying technology moved on; the marketing did not.
The TLS Handshake: A Conversation in Four Steps
Every HTTPS connection begins with a brief ceremony called the TLS handshake. It happens in milliseconds and you never see it, but understanding it demystifies everything else. Here's the plain-English version.
Step 1 — Client Hello
Your browser opens the conversation. It tells the server: "Here's which versions of TLS I understand, here's a list of encryption methods I support, and here's a random number I just generated." That random number will matter later. Think of this as your browser arriving at a negotiation table and putting its capabilities on the table first.
Step 2 — Server Hello
The server responds: "Fine, let's use TLS 1.3, let's use this encryption method from your list, and here's my own random number." Then it hands over its certificate — a digital document that proves who it is. Think of this as the server showing its passport.
Step 3 — Certificate Check
Your browser examines the certificate. It checks: Is this certificate valid today? Does it actually cover this domain name? And crucially — was it issued by someone I trust? This last question is what the entire certificate authority system is built to answer.
Step 4 — The Shared Secret
Once the certificate checks out, both sides use the two random numbers they exchanged, plus some clever maths (key agreement algorithms like ECDHE), to independently arrive at the exact same secret key — without ever actually sending that key across the network. It's like two people agreeing on a colour by each mixing paint in a way that produces the same shade, even though neither shared their individual mixing recipe. With that shared key, all subsequent communication is encrypted symmetrically — fast, cheap, and unreadable to anyone else.
The genius of the TLS handshake is that both sides end up with the same secret key without ever sending it. A wiretapper watching the whole conversation still can't compute the key.
What Is a Certificate — and Who Issues Them?
A TLS certificate is essentially a signed statement that says: "This public key belongs to the owner of example.com." The signature comes from a Certificate Authority (CA) — an organisation that your operating system and browser already trust. There are about a hundred major CAs in the world: DigiCert, Sectigo, GlobalSign, and others. Your browser ships with a built-in list of trusted CAs, so when a server presents a certificate signed by one of them, your browser already knows to trust it.
If you try to create a certificate yourself and sign it yourself (a "self-signed certificate"), browsers will throw a big red warning screen. Not because your encryption is weaker, but because there's no trusted third party vouching for your identity. It's the difference between a handwritten note saying "I am definitely a doctor" and an actual medical licence issued by a licensing board.
Let's Encrypt Made It Free
Until around 2015, certificates cost money — sometimes significant money. This was a genuine barrier for small sites and developers, and it's partly why so much of the early web ran on HTTP. Then the Internet Security Research Group launched Let's Encrypt, a non-profit CA backed by Mozilla, Google, and others. Let's Encrypt issues certificates for free, automatically, and renewably every 90 days. Today there is no legitimate cost reason to run a site without HTTPS. None. The padlock is free.
What the Padlock Verifies — and What It Does Not
Here's where people get tripped up, and where the padlock earns some nuance. The padlock means two things and two things only:
- Your connection to this server is encrypted. Nobody on the network between you and the server can read the traffic.
- The server's certificate was issued for this domain by a trusted CA. The domain in the address bar matches the certificate.
The padlock does not mean the website is trustworthy, legitimate, or safe. A phishing site designed to steal your banking credentials can have a perfectly valid, padlocked HTTPS connection. The lock just means your fake bank connection is private. Scammers figured this out early: Let's Encrypt's automated, free issuance means getting a certificate for secure-login-yourbank.com takes about thirty seconds.
So the padlock answers the question "is this connection private?" It cannot answer "is this site honest?" Those are different questions. Always check the domain name itself — not just the padlock.
Mixed Content: When HTTPS Goes Halfway
A page served over HTTPS can still undermine itself by loading resources — images, scripts, stylesheets — over plain HTTP. This is called mixed content, and browsers hate it. A script loaded over HTTP can be intercepted and replaced before it reaches the page, which would let an attacker inject malicious code into an otherwise secure page.
Modern browsers block active mixed content (scripts and iframes) silently and warn about passive mixed content (images). When you migrate a site to HTTPS and suddenly half your assets go missing, mixed content is usually the culprit. The fix is simple in principle: update every resource URL to use HTTPS. The hunt for them is less simple — which is why a proper HTTP-to-HTTPS migration involves a content audit, not just flipping a setting.
Why HTTP Is Dangerous in Practice
It's easy to dismiss the HTTP risk as theoretical. It isn't. Three concrete attack scenarios happen daily:
- Packet sniffing on public Wi-Fi. Open networks at cafes, airports, and hotels do not encrypt traffic between your device and the router. Anyone on the same network with freely available tools like Wireshark can read every unencrypted HTTP request you make — including cookies, form data, and session tokens.
- ISP injection. Internet service providers in multiple countries have been caught inserting their own advertisements, tracking pixels, or notifications directly into HTTP responses. They literally modify the webpage between the server and you. HTTPS makes this impossible.
- Man-in-the-middle attacks. On compromised networks, an attacker can intercept HTTP requests and serve a forged response — a login page that looks identical to the real one but sends your credentials to them instead. HTTPS certificate validation breaks this attack because the attacker cannot produce a valid certificate for your bank's domain.
HTTPS Is Faster Than HTTP (Yes, Really)
One persistent myth is that HTTPS is slower because of the handshake overhead. In 2026, the opposite is broadly true. HTTP/2 — the modernised version of the protocol that enables multiplexing, header compression, and server push — requires HTTPS in all major browser implementations. HTTP/1.1 was the last version to work over plain HTTP. The performance wins from HTTP/2 (and HTTP/3, which runs over QUIC) dramatically outweigh the negligible overhead of the TLS handshake, especially since TLS 1.3 reduced the handshake from two round trips to one.
Google has also factored HTTPS into its search ranking signals since 2014. All else being equal, an HTTPS site ranks above its HTTP equivalent. It's a small signal among hundreds, but it's a free win that costs nothing to capture.
HSTS: Locking the Door Behind You
Even after you enable HTTPS, there's a window of risk on a user's very first visit if they type your domain without a scheme (just example.com rather than https://example.com). The browser may try HTTP first and then get redirected — and that initial HTTP request is exposed. HTTP Strict Transport Security (HSTS) closes this gap.
With HSTS, your server sends a header telling the browser: "For the next year, never attempt to connect to this domain over HTTP — go straight to HTTPS, even before making a request." The browser remembers this and enforces it locally. There is also an HSTS preload list built into browsers that covers major domains even on their very first visit, before the browser has ever seen that header. If your site handles anything sensitive, HSTS with a long max-age is the logical last step in a proper HTTPS setup.
The "My Site Doesn't Need HTTPS" Argument, Retired
The argument usually goes: "It's just a static blog. Nobody's logging in. There's no sensitive data. Why bother?" Here's why every single one of those points is beside the point.
First, your visitors' browsing behaviour is sensitive data even if the content isn't. An ISP knowing that someone in a particular household reads articles about addiction recovery, political opposition, or medical conditions is genuinely invasive, regardless of whether you consider your blog "sensitive." Second, browsers now flag HTTP sites with a visible "Not Secure" label in the address bar. That label erodes trust and increases bounce rates. Third, free certificates from Let's Encrypt eliminate the cost argument entirely. And fourth, as noted above, you're leaving HTTP/2 performance on the table.
There is no site for which "HTTP is fine." There are only sites that haven't been migrated yet.
The Short Version
HTTPS wraps your web traffic in TLS encryption so that nobody between your browser and the server can read or tamper with it. The TLS handshake establishes a shared secret without ever transmitting it. Certificates, signed by trusted Certificate Authorities, prove you're actually talking to the server you think you are. Let's Encrypt made all of this free in 2015 and removed the last credible objection to universal HTTPS adoption. The padlock means your connection is private and the domain is verified — it does not mean the site itself is trustworthy. And with HSTS and HTTP/2 in the picture, HTTPS is not just safer than HTTP. In every measurable way, it is also faster and better for your site's discoverability.
Next time you see that padlock, you'll know exactly what it earned — and exactly what it didn't promise.