HTTP to HTTPS Redirects Explained
Having an HTTPS version of your site is not the same thing as redirecting to it. A redirect is what actually moves a visitor from the unencrypted connection they started on to the encrypted one — without it, the encrypted version just sits there unused by anyone who didn't already know to ask for it.
Last updated August 11, 2026.
Why the redirect itself matters
When a browser has no other information, it requests http://by default — that's what happens when a visitor types a bare domain, follows an old link, or clicks a bookmark saved years ago. If the server simply serves the page over that connection instead of redirecting, the visitor's entire session stays unencrypted, even though an HTTPS version of the exact same page is sitting one hop away.
The redirect is the mechanism that closes that gap: a small, automatic response that moves every visitor onto the encrypted connection before any real content or form data is exchanged, regardless of how they arrived.
What a correct redirect chain looks like
A correct HTTP→HTTPS redirect is a single hop: the server responds to the http:// request with a 301 Moved Permanently status and a Location header pointing straight at the equivalent https:// URL, path and query string preserved.
GET http://example.com/pricing?ref=ad HTTP/1.1 HTTP/1.1 301 Moved Permanently Location: https://example.com/pricing?ref=ad
301 (permanent) is preferred over 302 (temporary) for this redirect because it lets browsers and search engines cache the fact that the site is HTTPS-only going forward, rather than re-checking on every visit.
Common mistakes
- Redirect loops.The HTTPS side redirects back to HTTP — often because a reverse proxy or CDN terminates TLS and forwards the request to the origin as plain HTTP, and the origin's own "force HTTPS" rule then redirects it right back. The fix is to trust the proxy's forwarded-protocol header (
X-Forwarded-Proto) instead of re-checking the scheme at the origin. - Redirecting to another HTTP URL. A rule written against a stale
http://canonical or a relative path can end up redirecting one insecure URL to another insecure URL — the connection never actually becomes encrypted. - Missing Location header. A 3xx status code with no
Locationheader gives the browser nowhere to go, which usually surfaces as a browser error rather than a redirect.
How this differs from — and complements — HSTS
A redirect and HSTS solve adjacent problems. The redirect handles a visitor's first request to a domain: it takes the insecure request that already went out and bounces it to HTTPS after the fact. HSTS goes a step further — once a browser has seen the HSTS header once, it rewrites http:// to https:// internally, before any request leaves the device at all, on every subsequent visit. A redirect without HSTS still has one unencrypted request per new visitor; HSTS removes that request entirely, but only after the browser has already seen it once — which is why the two are meant to be used together, not as alternatives.