HSTS vs HTTPS: What's the Difference?

HSTS and HTTPS are related but distinct. Learn how they work together, why HSTS matters, and how to verify both are correctly configured on your site.

1 June 2026·Uptrue Team

HSTS vs HTTPS: What's the Difference and Why Both Matter

By Krithi

If you've set up HTTPS on your site and called it a day, you're most of the way there — but not entirely. HSTS vs HTTPS is a question that trips up a surprising number of engineers who assume the two are interchangeable. They're not. One is a transport protocol; the other is a browser instruction. Understanding the gap between them is what separates a site that can serve traffic securely from one that always does.

What Is HTTPS?

HTTPS (HyperText Transfer Protocol Secure) is HTTP layered on top of TLS (Transport Layer Security). When a browser connects to your server over HTTPS, it:

Performs a TLS handshake, verifying your SSL/TLS certificate.
Negotiates an encryption cipher suite.
Encrypts all data in transit between the client and server.

That's it. HTTPS is a protocol — a set of rules for how data moves between two endpoints. It doesn't tell the browser to prefer HTTPS, or to refuse an HTTP connection. Left to its own devices, a browser will happily connect over plain HTTP if that's what the URL says or what a redirect delivers.

This is where the vulnerability lives. A user might type example.com into their address bar. The browser sends a plain HTTP request. Your server redirects them to https://example.com. Fine — until an attacker intercepts that first unencrypted request before the redirect fires. That attack is called an SSL stripping attack, and HTTPS alone does nothing to prevent it.

What Is HSTS?

HSTS stands for HTTP Strict Transport Security. It's not a protocol — it's a response header. When your server includes this header in an HTTPS response, the browser records a policy: for this domain, only ever connect over HTTPS, for the specified duration.

A minimal HSTS header looks like this:

` Strict-Transport-Security: max-age=31536000 `

A production-grade one includes subdomains and preloading:

` Strict-Transport-Security: max-age=63072000; includeSubDomains; preload `

What each directive does:

| Directive | Meaning | |---|---| | max-age | How long (in seconds) the browser should enforce HTTPS-only. One year = 31,536,000. | | includeSubDomains | Applies the policy to all subdomains, not just the root domain. | | preload | Opts the domain into browser preload lists, so HSTS is enforced even on a first visit. |

Once a browser has received and stored an HSTS policy, it won't even attempt an HTTP connection to that domain. It upgrades the request internally before any network traffic leaves the machine. The first-visit vulnerability that SSL stripping exploits? Gone — if you're on the preload list.

HSTS vs HTTPS: The Core Distinction

Think of it this way:

HTTPS is the lock on the door.

HSTS is the rule that says the door must always be locked and nobody is allowed to prop it open.

Both are necessary. HTTPS without HSTS means a window of plain HTTP exposure exists. HSTS without a valid HTTPS configuration is meaningless — the header must itself be served over a secure connection to be honoured by browsers.

Here's a quick comparison:

| | HTTPS | HSTS | |---|---|---| | Type | Transport protocol (TLS) | HTTP response header | | Configured in | Web server / CDN / load balancer | HTTP response headers | | Protects against | Eavesdropping, tampering | SSL stripping, downgrade attacks | | First-visit protection | Yes (if no HTTP endpoint) | Only with preloading | | Browser caches it? | No | Yes, for max-age duration | | Breaks on misconfiguration | Cert errors block the site | Expired cert = site becomes inaccessible |

Why HSTS Can Be a Double-Edged Sword

HSTS is powerful, but it's unforgiving. If you set a long max-age, deploy includeSubDomains, and then let your TLS certificate lapse — or move a subdomain to HTTP — every returning visitor will see a hard browser error, not a fallback. There's no override for end users; that's the point.

This is why monitoring matters as much as configuration. You need to know:

When your SSL/TLS certificate is approaching expiry.

Whether your HSTS header is still being served correctly after deployments.

Whether any subdomains covered by includeSubDomains have drifted away from HTTPS.

Uptrue's security headers monitoring tracks your HSTS header continuously and alerts you if it disappears, changes unexpectedly, or if the max-age drops below a safe threshold. Pair that with SSL certificate monitoring to catch expiring certificates before they cause an outage.

How to Implement HSTS Correctly

Step 1: Get HTTPS right first

Before you touch HSTS, make sure:

Your TLS certificate is valid and covers all subdomains you intend to protect.

All HTTP traffic is redirected to HTTPS at the server or CDN level.

Your certificate auto-renews reliably (Let's Encrypt or equivalent).

Step 2: Start with a short max-age

Begin with a small value — say, five minutes (max-age=300) — while you verify nothing breaks. Once you're confident, ramp up progressively: one day, one week, one month, then one year or two.

Step 3: Add includeSubDomains cautiously

Only add includeSubDomains after you've audited every subdomain. A forgotten staging environment running on HTTP will break for any user whose browser has cached your HSTS policy.

Step 4: Apply for HSTS preloading

Visit hstspreload.org to submit your domain. Requirements include:

A valid certificate.

Redirect from HTTP to HTTPS.

max-age of at least 31,536,000 seconds (one year).

includeSubDomains directive present.

preload directive present.

Preloading is irreversible in the short term — removal from the list can take months to propagate. Don't rush this step.

Checking Your Current HSTS Configuration

Not sure if your site is sending the right header? You can inspect it yourself with curl:

`bash curl -sI https://yourdomain.com | grep -i strict `

You should see output like:

` strict-transport-security: max-age=63072000; includeSubDomains; preload `

If nothing is returned, the header isn't being sent. If the max-age is very low (or zero), your HSTS policy is effectively disabled.

For a quicker check, use Uptrue's free security headers tool to scan any URL and see a full breakdown of which headers are present, missing, or misconfigured — no account required.

!Diagram showing the difference between HTTPS encryption and HSTS browser enforcement

The Risk of Getting This Wrong

SSL stripping attacks are not theoretical. They're a documented, practical attack used against poorly configured sites — particularly on untrusted networks like public Wi-Fi. A user connects to http://yourbank.com, the attacker intercepts and downgrades the connection, the user never sees any warning. HTTPS alone doesn't prevent this. HSTS, and specifically HSTS preloading, does.

Beyond active attacks, there's the reputational and compliance angle. Security audits, penetration tests, and compliance frameworks (PCI DSS, ISO 27001) all look for HSTS. Missing it is a finding. It's a low-effort control with high impact.

Keep an Eye on Both, Continuously

Configuring HSTS and HTTPS correctly at launch is table stakes. The real risk comes from drift: a deployment pipeline that drops the header, a certificate renewal that fails silently, a new subdomain spun up without HTTPS.

Monitor your security headers automatically. Uptrue checks your HSTS header, SSL certificate, DNS configuration, and uptime from multiple locations — and alerts you the moment something changes. Start monitoring for free — no credit card required.

Summary

HTTPS encrypts data in transit using TLS. It's the foundation, but it doesn't force browsers to use it.

HSTS instructs browsers to always use HTTPS for your domain, eliminating the HTTP window that SSL stripping exploits.

Both are required for a genuinely secure site. HTTPS without HSTS leaves a first-connection vulnerability. HSTS without HTTPS is invalid.

Implement HSTS incrementally, audit your subdomains, and consider preloading for maximum protection.

Monitor both continuously — configuration drift is the most common source of real-world failures.

Security isn't a checkbox. It's an ongoing state. Make sure you have visibility into both.