HTTP vs HTTPS: what the S actually changes

HTTP and HTTPS are the same protocol. Every header, method, and status code works identically in both. The S adds exactly one thing: before any HTTP data flows, the connection is wrapped in TLS, an encrypted and authenticated tunnel between the browser and the server. That one layer changes what an attacker on the network can see, what they can modify, and what the browser is willing to let a page do.

What actually differs

Plaintext HTTP means every router, wifi access point, ISP, and proxy between you and the server can read the complete request and response: URLs, cookies, passwords, form data, page content. They can also change it in transit, which is how some ISPs historically injected ads into pages. TLS closes both doors: the content is unreadable and any modification causes the connection to fail rather than silently deliver altered data.

What HTTPS encrypts, and what it leaks

Once the TLS handshake completes, everything inside is protected: the path and query string, headers, cookies, request bodies, and the response. An observer cannot tell whether you loaded /pricing or /admin/delete-everything.

HTTPS does not hide everything, though:

• The domain you visited. DNS lookups and the TLS SNI field reveal example.com (though not the page) unless encrypted DNS and ECH are in play.
• Traffic size and timing. Metadata analysis is still possible.
• Anything on the server itself. HTTPS secures the transport, not the destination. A phishing site with a valid certificate is still a phishing site; the padlock means "encrypted connection to this domain," not "trustworthy domain."

The certificate is the interesting part

Encryption without identity is useless, since you might be encrypting straight to an attacker performing a man in the middle. So HTTPS servers present a certificate: a statement, signed by a certificate authority the browser already trusts, that the server holding this private key is legitimately example.com. The browser verifies the signature chain, checks the expiry date and the domain match, and only then proceeds.

This is why HTTPS failures are almost always certificate problems rather than encryption problems: expired certificates, missing intermediate certificates, or a certificate that does not cover the requested hostname. The TLS handshake explained walks through the full sequence, and fixing certificate chain errors covers the most common server misconfiguration.

Certificates are free now. Let's Encrypt issues them automatically, most hosting platforms (Vercel, Netlify, Cloudflare) provision and renew them without any action from you, and the historical cost argument for staying on HTTP is gone.

Why HTTPS is no longer optional

• Browsers enforce it. Chrome and Firefox label every HTTP page "Not secure," and powerful APIs (geolocation, camera, service workers, clipboard) only work in secure contexts.
• HTTP/2 and HTTP/3 require it. The speed benefits of multiplexed and QUIC-based connections are HTTPS-only in every browser, so an HTTPS site is typically faster than its HTTP equivalent today, reversing the old performance argument.
• SEO. Google confirmed HTTPS as a ranking signal in 2014, and Chrome's warnings hurt engagement on HTTP pages beyond any algorithmic effect.
• Referrer data. Browsers strip referrer information when moving from HTTPS to HTTP, so HTTP sites see less of their inbound analytics.

Moving a site to HTTPS cleanly

1. Get and install a certificate, or let your host do it. Confirm the full chain is served, not just the leaf certificate.
2. Redirect HTTP to HTTPS with a 301 so links and search engines consolidate on the secure origin. Get the status code right: 301 vs 302 matters here.
3. Fix mixed content. A page loaded over HTTPS that pulls scripts or images over HTTP gets those requests blocked or the padlock downgraded. Update hardcoded http:// asset URLs.
4. Add HSTS once everything works: the Strict-Transport-Security header tells browsers to skip the insecure redirect hop entirely on future visits.
5. Verify from the outside. Check the certificate chain, expiry, protocol versions, and redirect behavior as an external client sees them.

The SSL Checker does that last step in one paste: it reports the certificate, its chain, expiry dates, and supported TLS versions for any domain, so you can confirm the S is actually doing its job.