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

What HTTPS actually does#

HTTPS stands for Hypertext Transfer Protocol Secure. It is the standard protocol for encrypted communication between a web browser and a server. When you visit a site over HTTPS, the browser and server perform a TLS handshake, which is a short exchange that establishes a shared encryption key. From that point on, every byte of data traveling between the two is encrypted. Anyone sitting on the network between them sees only scrambled traffic.

This is what the padlock icon in the address bar represents. It tells the visitor that the connection is encrypted and that the server has presented a valid TLS certificate proving it controls the domain. HTTPS protects against eavesdropping, where someone on a public Wi-Fi network reads the traffic, and against tampering, where someone on the network modifies the page content before it reaches the browser.

What HTTPS does not do is guarantee that the browser will always use it. A visitor can type http://example.com in the address bar. A bookmark from years ago might use an HTTP URL. An email or document might contain an old link without the https:// prefix. In all of those cases, the browser will attempt a plain HTTP connection first. HTTPS is ready and waiting on the server, but the browser does not know to ask for it yet.

The gap HTTPS leaves open#

Most sites that support HTTPS also set up a server-side redirect. When a request arrives over HTTP, the server responds with a 301 (permanent redirect) pointing the browser to the HTTPS version of the same URL. The browser follows the redirect, connects over HTTPS, and everything proceeds securely from there.

The problem is that first request. Before the redirect happens, the browser has already sent an unencrypted HTTP request across the network. That request contains the full URL the visitor is trying to reach, any cookies the browser has for that domain (unless they are flagged as Secure), and the visitor's IP address. All of that travels in plain text. On a coffee shop Wi-Fi network, a compromised router, or any other untrusted network, someone watching the traffic can see everything in that initial request.

Worse, the redirect itself is vulnerable. An attacker performing an SSL stripping attack intercepts the HTTP request before the server's 301 redirect reaches the browser. The attacker connects to the real server over HTTPS, so the server thinks everything is fine. But the attacker serves the victim plain HTTP, sitting invisibly between the two. The visitor sees a working page with no padlock. The attacker reads and modifies every piece of data in both directions.

This is the fundamental gap. HTTPS only protects connections that actually use it. The redirect approach relies on the attacker being honest enough to pass the redirect along, which is exactly the thing you cannot count on.

What HSTS adds on top of HTTPS#

HSTS stands for HTTP Strict Transport Security. It is a response header that your server sends along with HTTPS responses. The header looks like this:

When the browser receives this header over a valid HTTPS connection, it remembers the instruction for the duration specified by max-age (measured in seconds). From that point on, any attempt to visit the site over HTTP is converted to HTTPS inside the browser itself, before any network request is made. The browser does not ask the server. It does not wait for a redirect. It rewrites the URL on its own.

This is the key difference. With only HTTPS and a redirect, the security of the first request depends on the network being safe. With HSTS, the browser takes the network out of the equation entirely. It already knows this domain requires HTTPS, so it never sends an unencrypted byte.

The header has three directives. max-age sets how long the browser remembers the policy, in seconds. A value of 63072000 is two years, which is the recommended minimum for production sites. includeSubDomains extends the policy to every subdomain under the main domain, which prevents an attacker from finding an unprotected subdomain and using it as an entry point. preload signals that the site owner wants the domain added to the browser's built-in preload list, which is covered in a later section.

What HSTS defends against that HTTPS alone does not

• SSL stripping attacks that intercept the initial HTTP request
• Protocol downgrade attacks on untrusted networks
• Cookie leakage over accidental HTTP connections
• Bookmark and link rot from old HTTP URLs
• User error when typing http:// instead of https://

The 307 internal redirect#

When HSTS is active and a browser encounters an HTTP URL for the protected domain, it issues a special redirect with status code 307. Unlike a normal 301 or 302 redirect that comes from the server, this 307 happens entirely inside the browser. No network traffic is generated. The browser simply rewrites http:// to https:// and proceeds with the HTTPS connection.

You can see this for yourself in Chrome DevTools. Open the Network tab, navigate to an HTTP URL for a site that sends an HSTS header, and look at the first entry. It will show a 307 status code with "Internal Redirect" in the initiator column. The response headers will include Non-Authoritative-Reason: HSTS, confirming that the redirect was triggered by the HSTS policy rather than by the server.

The timing difference is significant. A server-side 301 redirect requires a full round trip: the browser sends an HTTP request, waits for the server to respond, receives the redirect, and then opens a new HTTPS connection. That round trip adds latency to every HTTP navigation. The HSTS 307 internal redirect skips the round trip entirely. The browser converts the URL instantly and connects over HTTPS on the first network request. This means HSTS is not only more secure than a redirect, it is also faster.

HSTS preload: closing the last gap#

There is one scenario that HSTS alone does not cover: the very first visit. A browser can only learn about an HSTS policy by receiving the header over a valid HTTPS connection. If a visitor has never been to your site before, the browser has no cached policy. That first navigation to an HTTP URL will still go out unencrypted, exactly like it would without HSTS.

This is called the trust on first use problem, and the solution is the HSTS preload list. The preload list is a directory of domains that is compiled by the Chromium project and shipped inside the browser binary. Chrome, Firefox, Safari, and Edge all use versions of this list. When a domain is on the preload list, the browser knows to use HTTPS before it has ever visited the site. There is no first-visit vulnerability because the policy is baked into the browser itself.

To qualify for the preload list, your HSTS header must include all three directives: a max-age of at least 31536000 (one year), the includeSubDomains directive, and the preload directive. You also need to serve the header from the root domain (not just a subdomain) and have a valid redirect from HTTP to HTTPS in place. Once your configuration meets those requirements, you submit your domain at hstspreload.org and wait for the next browser release cycle to pick it up.

The three levels of protection

Putting it all together, there are three levels of HTTPS enforcement, each closing a gap left by the one before it:

• HTTPS with a redirect protects connections after the first unencrypted request reaches the server. The initial request is exposed.
• HTTPS with HSTS protects every connection after the first visit. The browser remembers the policy and never sends plain HTTP again. The very first visit is still exposed.
• HTTPS with HSTS preload protects every connection from the very first visit. The browser ships with the policy already in place. No unencrypted request is ever sent.

How to enable HSTS#

Enabling HSTS is a single header addition, but it should be done carefully. The recommended approach is to start with a short max-age (300 seconds, which is five minutes), verify that nothing breaks, then increase it to a week, then a month, then two years. This incremental rollout lets you catch problems before committing to a long policy duration.

# Apache (.htaccess or VirtualHost)
# Step 1: redirect HTTP to HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# Step 2: add HSTS header on HTTPS responses
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

# Nginx
# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

# HTTPS server block
server {
    listen 443 ssl;
    server_name example.com;

    # Add HSTS header
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # ... rest of your config
}

// Node.js / Express
const helmet = require('helmet');

// Enables HSTS with a two-year max-age, includeSubDomains, and preload
app.use(helmet.hsts({
  maxAge: 63072000,
  includeSubDomains: true,
  preload: true
}));

One important detail: only send the HSTS header over HTTPS, never over HTTP. If an attacker can intercept an HTTP response and inject a fake HSTS header with a short max-age of zero, they can wipe out the browser's cached policy. Browsers are designed to ignore HSTS headers received over plain HTTP, but your server configuration should enforce this as well.

How to check your setup#

The fastest way to check whether your site sends an HSTS header is to open your browser's developer tools. Navigate to your site, open the Network tab, click the initial document request, and scroll down to the response headers. Look for a Strict-Transport-Security header. If it is there, note the max-age value and whether includeSubDomains is present.

From the command line, you can use curl -sI https://example.com | grep -i strict to check the header directly. If the command returns nothing, HSTS is not configured.

To verify the 307 internal redirect, type an HTTP URL for a site you have already visited with HSTS enabled. In Chrome's Network tab, you should see a 307 status code on the first entry with "Internal Redirect" as the initiator. If you see a 301 from the server instead, it means the browser does not have a cached HSTS policy for that domain.

To check preload status, visit hstspreload.org and enter your domain. The tool will tell you whether the domain is on the preload list, whether it is pending, and whether your current header configuration meets all the requirements.

To verify the underlying TLS connection itself, the TLS Handshake Checker shows the protocol version, cipher suite, and certificate chain your server negotiates. HSTS depends on a working HTTPS setup, so confirming the handshake is healthy is a good first step before focusing on the header.

SiteSecurityScore checks for HSTS as part of its header analysis. It flags missing HSTS headers, short max-age values, missing includeSubDomains, and the absence of the preload directive so you can see exactly where your configuration stands.

FAQ#