What is mixed content and why is it a problem?

Mixed content occurs when an HTTPS page loads some resources — images, scripts, iframes — over plain HTTP. Passive mixed content (images, audio) is displayed with a warning or blocked. Active mixed content (scripts, stylesheets, iframes) is blocked entirely by modern browsers because a man-in-the-middle attacker could manipulate those resources and take control of the page, defeating the security of HTTPS entirely. Fix it by updating all resource URLs to HTTPS.

HTTP Strict Transport Security (HSTS) is a security header that instructs browsers to always connect to a domain via HTTPS, never HTTP, for a specified duration (the max-age). Once a browser has seen the HSTS header, it automatically upgrades any HTTP request to HTTPS without making a round trip to the server first. Adding the domain to the HSTS preload list bakes this rule into browsers before the very first visit, eliminating the initial insecure request entirely.

Does HTTPS affect SEO?

Yes. Google confirmed HTTPS as a ranking signal in 2014. Sites still serving plain HTTP are marked "Not Secure" in Chrome's address bar, which increases bounce rates. Free certificates from Let's Encrypt remove the cost barrier entirely, so there is no reason not to use HTTPS for any production site. Major search engines crawl HTTPS URLs preferentially, and any HTTP to HTTPS redirect adds a small but unnecessary extra round trip.

Does HTTPS encrypt the URL path and query string?

Yes — the full URL path, query string, and request body are encrypted by TLS. Only the domain name (via SNI — Server Name Indication) is visible during the handshake so the server knows which certificate to present. The IP address and domain are visible to network observers; everything else — path, parameters, cookies, headers, body — is encrypted.

Web security comparison

HTTP vs HTTPS

One transmits data in plain text that anyone on the network can read. The other wraps every byte in encryption. Understanding what TLS does — and what it does not do — is essential vocabulary for any developer working on the web.

TL;DR

HTTP — plain-text protocol on port 80. No encryption, no authentication. Fine for local development; unacceptable for production.
HTTPS — HTTP layered over TLS on port 443. All data is encrypted in transit, the server's identity is verified via a CA-signed certificate, and data integrity is guaranteed. Free certificates via Let's Encrypt remove the only remaining cost barrier.
For any production site: use HTTPS, enforce it with HSTS, and redirect HTTP to HTTPS with a permanent 301.

Side-by-side comparison

Aspect	HTTP	HTTPS
Default port	80	443
Encryption	None — plain text on the wire	TLS (Transport Layer Security)
Server authentication	None — no proof of server identity	Certificate verified by a trusted CA
Data integrity	Can be modified in transit	Tampering detected and rejected by TLS
Man-in-the-middle risk	High — traffic is readable and editable	Mitigated — attacker cannot read or alter data
Certificate required	No	Yes — issued by a CA (e.g. Let's Encrypt, free)
Browser treatment	"Not Secure" warning in Chrome/Firefox	Padlock shown; no warning
SEO / ranking	Ranking disadvantage vs HTTPS	Confirmed Google ranking signal (since 2014)
HTTP/2 & HTTP/3	Browsers do not use HTTP/2 over plain HTTP	Required by all browsers for HTTP/2 and HTTP/3

What is HTTP?

HTTP (HyperText Transfer Protocol) is the application-layer protocol at the foundation of the web. A client sends a request — a method such as GET or POST, a path, headers, and optionally a body — and the server responds with a status code, headers, and the resource body. Everything travels as unencrypted text over TCP on port 80.

The problem is that plain HTTP has no mechanism to verify you are talking to the right server, no protection against a third party reading your traffic, and no guarantee that the response was not altered in transit. On any shared network — a coffee-shop Wi-Fi, a corporate proxy, a compromised router — anyone running a packet sniffer sees every HTTP request and response verbatim, including session cookies, form submissions, and authentication tokens.

What is HTTPS?

HTTPS is HTTP transported over a TLS (Transport Layer Security) connection on port 443. TLS provides three properties that plain HTTP lacks:

Confidentiality — data is encrypted using symmetric keys negotiated during the TLS handshake. Only the two endpoints can decrypt the traffic.
Integrity — each TLS record includes a Message Authentication Code (MAC). Any in-transit modification is detected and the connection is closed.
Authentication — the server presents a digital certificate signed by a Certificate Authority (CA). The browser verifies the signature against its list of trusted root CAs, confirming the server is who it claims to be and preventing man-in-the-middle attacks.

The TLS handshake

Before any HTTP data is exchanged over an HTTPS connection, a TLS handshake establishes the encrypted channel:

ClientHello — the browser announces supported TLS versions and cipher suites.
ServerHello — the server selects a cipher suite and sends its certificate.
Certificate verification — the browser validates the certificate chain up to a trusted root CA. If validation fails, the browser blocks the connection.
Key exchange — client and server derive shared session keys (using Diffie-Hellman ephemeral key exchange in TLS 1.3) without the keys ever travelling across the wire.
Finished — both sides confirm the handshake with a MAC and begin encrypted communication.

TLS 1.3, the current version since 2018, reduced this to a single round trip (1-RTT) and supports 0-RTT resumption for repeat connections, making the historical performance argument against HTTPS essentially obsolete.

# Check which TLS version and cipher a server negotiates
openssl s_client -connect example.com:443 -tls1_3

# Inspect the certificate details (issuer, expiry, SAN)
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text

# Obtain a free 90-day certificate with Let's Encrypt (Certbot + Nginx)
sudo certbot --nginx -d example.com -d www.example.com

# Test HSTS header presence
curl -sI https://example.com | grep -i strict

HSTS — enforcing HTTPS at the browser level

Even with a permanent redirect from HTTP to HTTPS, the very first request a new visitor makes travels as plain HTTP before the redirect arrives. An attacker performing a man-in-the-middle attack could intercept that initial request and never let the redirect happen — a technique called an SSL stripping attack.

HTTP Strict Transport Security (HSTS) fixes this. When a browser receives the Strict-Transport-Security response header it records a rule: for the specified max-age, never send plain HTTP to this domain — upgrade automatically. The header looks like:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Adding preload and submitting to hstspreload.org bakes the rule into Chrome, Firefox, Safari, and Edge before the very first visit, eliminating the insecure initial request entirely. Note: once added to the preload list, removing a domain is difficult — only add it when you are certain all subdomains can serve HTTPS.

Mixed content

A common migration pitfall is mixed content — an HTTPS page that loads some resources (images, scripts, iframes) over HTTP. Browsers distinguish two types:

Passive mixed content — images, audio, video referenced via HTTP. Modern browsers now block or auto-upgrade these; older browsers showed a warning.
Active mixed content — scripts, stylesheets, and iframes loaded over HTTP. Blocked by all modern browsers because a compromised script can take over the entire page, defeating the purpose of HTTPS entirely.

Fix mixed content by updating all resource references to HTTPS. Use the Content-Security-Policy: upgrade-insecure-requests header as a fallback to automatically rewrite HTTP subresource URLs to HTTPS at the browser level.

Let's Encrypt and free certificates

Before Let's Encrypt launched in 2016, obtaining a certificate required paying a commercial CA and going through a manual validation process. Let's Encrypt changed this: it provides free Domain Validation (DV) certificates automatically via the ACME protocol, with 90-day validity and support for automated renewal via tools like Certbot, Caddy, and most hosting control panels. The 90-day lifetime is intentional — it limits the window of exposure if a key is compromised and encourages automation over manual processes.

How engineers talk about HTTP vs HTTPS

Security and certificates

"We need to provision an SSL cert before we go live." (Engineers commonly say "SSL" even when they mean TLS.)
"The cert is issued by Let's Encrypt and auto-renews every 90 days — nothing to manage."
"The TLS handshake failed — check the certificate chain is complete and the intermediate cert is included."
"We've got mixed content on the checkout page — one image is still loading over HTTP."

Enforcement and deployment

"Add the HSTS header with a long max-age once you're confident everything is HTTPS."
"Traffic could be sniffed on the wire without HTTPS — not acceptable for an API that handles user data."
"Redirect all HTTP traffic to HTTPS at the load balancer, not in the app."
"Make sure port 443 is open in the security group and port 80 redirects."

Key vocabulary

TLS (Transport Layer Security) — the cryptographic protocol that provides encrypted, authenticated connections. TLS 1.3 is current; SSL and TLS 1.0/1.1 are deprecated and insecure.
SSL certificate — a digital certificate binding a domain name to a public key, signed by a Certificate Authority. Despite the name, modern certificates are used with TLS, not SSL.
CA (Certificate Authority) — a trusted organisation (e.g. Let's Encrypt, DigiCert, Sectigo) that verifies identity and signs certificates. Browsers trust a pre-installed list of root CAs.
TLS handshake — the negotiation phase at the start of a TLS connection: cipher suites are agreed, the certificate is verified, and session keys are derived without travelling over the wire.
HSTS (HTTP Strict Transport Security) — a response header instructing browsers to only ever connect via HTTPS for a specified period, preventing downgrade attacks.
Mixed content — HTTP subresources loaded on an HTTPS page. Active mixed content (scripts, iframes) is blocked by browsers; passive mixed content (images) is often blocked or auto-upgraded.
Man-in-the-middle (MITM) attack — an attacker secretly intercepts and potentially alters traffic between two parties. HTTPS prevents this by encrypting and authenticating the connection.
Let's Encrypt — a free, automated, open CA run by the non-profit ISRG. Issues 90-day certificates via ACME with auto-renewal, making HTTPS accessible to everyone at zero cost.
Encryption in transit — protecting data while it travels across a network, as opposed to encryption at rest. HTTPS provides encryption in transit.
Port 80 / port 443 — the default TCP ports for HTTP and HTTPS respectively. Production servers typically listen on both, redirecting 80 to 443.

Decision guide

Building any production website or API → HTTPS only
Running a local development server → HTTP is fine (or use mkcert for local HTTPS)
Handling passwords, payment data, or personal data → HTTPS mandatory — legally required in most jurisdictions
Want HTTP/2 or HTTP/3 → HTTPS required — all major browsers enforce TLS for these protocols
Migrating an existing HTTP site → 301 redirect HTTP to HTTPS + add HSTS header
Using a CDN or load balancer → TLS termination at the edge; consider internal TLS for backend traffic too
Certificate cost is a concern → Let's Encrypt — free, 90-day, auto-renewing
Need extended validation for high-trust contexts → Paid OV or EV certificate from a commercial CA

Frequently asked questions

What is the difference between HTTP and HTTPS?

HTTP (HyperText Transfer Protocol) transmits data in plain text — anyone who can intercept the traffic can read or modify it. HTTPS adds a TLS (Transport Layer Security) layer on top of HTTP, encrypting all data in transit so that only the client and the server can read it. HTTPS also authenticates the server via a digital certificate issued by a Certificate Authority, confirming you are connected to the real site and not an impostor.

Is SSL the same as TLS?

Not exactly. SSL (Secure Sockets Layer) was the original protocol, with versions 2.0 and 3.0 released in the 1990s. TLS (Transport Layer Security) is its successor — TLS 1.0 was effectively SSL 4.0. All SSL versions and TLS 1.0/1.1 are now considered insecure and deprecated. Modern HTTPS uses TLS 1.2 or TLS 1.3. Despite this, engineers often use "SSL" colloquially to mean TLS, and tools still use terms like "SSL certificate" even when they mean a TLS certificate.

What is a Certificate Authority (CA)?

A Certificate Authority is a trusted organisation that issues digital certificates after verifying the identity of the applicant. Browsers and operating systems ship with a list of trusted root CAs. When your browser connects to a site over HTTPS, it checks that the site's certificate was signed by a trusted CA. Let's Encrypt is a free, automated CA run by the non-profit Internet Security Research Group (ISRG); it issues certificates valid for 90 days and supports auto-renewal.

Show more questions (4)