HTTP vs HTTPS

HTTPS is HTTP with a TLS layer underneath. That layer adds encryption, integrity checking, and server authentication — three properties that plain HTTP entirely lacks. HTTPS is now the expected default for all public web content.

Quick Comparison

Feature	HTTP	HTTPS
Default port	80	443
Encryption	None — plaintext	TLS encryption
Data integrity	None — content can be modified in transit	TLS MAC prevents silent modification
Server authentication	None	TLS certificate authenticates the server
Browser indicator	"Not Secure" warning	Secure (padlock or no warning)
HSTS support	No	Yes — forces future visits over HTTPS
Mixed content risk	N/A	HTTP sub-resources blocked or flagged
Search ranking	Disadvantaged	Preferred by search engines
Certificate cost	N/A	Free (e.g. Let's Encrypt)

What TLS Adds

When a browser connects to an HTTPS site, it performs a TLS handshake before any HTTP data flows. That handshake establishes three things:

• Encryption. All HTTP headers and body content are encrypted. An ISP, a Wi-Fi network, or a man-in-the-middle cannot read what the browser sends or receives.
• Integrity. TLS uses message authentication codes to detect any modification to data in transit. Content injection — common with HTTP on some ISPs, which would insert ads or tracking scripts into pages — is not possible over HTTPS.
• Server authentication. The TLS certificate, signed by a trusted Certificate Authority, proves the server is who it claims to be. Without this, a browser connecting to https://example.com could be silently redirected to an attacker's server.

Ports: 80 vs 443

HTTP defaults to port 80. HTTPS defaults to port 443. Servers often listen on both: port 80 to receive plain HTTP requests and immediately redirect them to HTTPS, and port 443 to serve the actual content. The redirect is typically a permanent 301 so browsers remember to go directly to HTTPS on future visits.

Mixed Content

Mixed content occurs when an HTTPS page loads resources — scripts, stylesheets, images, iframes — over HTTP. Active mixed content (scripts and iframes) is blocked by all major browsers because a compromised HTTP resource could undermine the security of the otherwise encrypted page. Passive mixed content (images and video) may load but triggers a browser warning. Fixing mixed content means ensuring every resource URL in the page uses HTTPS.

HSTS and the First-Visit Problem

Even with HTTPS deployed, the first HTTP request to a site is unencrypted. HTTP Strict Transport Security (HSTS) solves part of this: once a browser receives an HSTS header over HTTPS, it refuses to connect to that domain over HTTP for the duration specified, converting any HTTP request to HTTPS internally before it leaves the device. HSTS preloading extends this further by shipping a list of HSTS domains inside browsers so even the very first visit is secure.

HTTPS adoption was historically slowed by the cost and complexity of obtaining TLS certificates from Certificate Authorities. Free automated certificate issuance (for example, through Let's Encrypt) removed that barrier. Today there is no cost reason to serve public web content over plain HTTP.

Audit your security headers →