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. Fix the proxy leg at the same time: on Cloudflare that means the SSL/TLS encryption mode set to "Full (strict)", not "Flexible" — Flexible stops the loop by talking to your origin over plain HTTP, which leaves the connection unencrypted for its last hop and recreates the exact problem the redirect exists to solve. - 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.
Related
FAQ
Should I use a 301 or 302 redirect for HTTP to HTTPS?
301 (Moved Permanently). It lets browsers and search engines cache the fact that the site is HTTPS-only going forward, so repeat visits and crawls skip straight to the HTTPS URL instead of re-checking HTTP first every time. 302 signals the move is temporary, which defeats that caching benefit.
Why is my HTTPS redirect looping back to HTTP?
The most common cause is a reverse proxy or CDN terminating TLS and forwarding the request to the origin as plain HTTP, while the origin's own force-HTTPS rule checks the connection scheme it actually received (HTTP) and redirects again. The fix is trusting the X-Forwarded-Proto header from the proxy instead of re-checking the scheme at the origin — and on Cloudflare specifically, setting SSL/TLS mode to Full (strict) rather than Flexible, since Flexible is what causes the origin to see plain HTTP in the first place.
Does an HTTPS redirect alone protect the first request from interception?
No — the browser's very first request still goes out over plain HTTP by default (typing a bare domain, an old bookmark, a stale link), and that single request is interceptable before the redirect ever happens. HSTS is what closes that gap: once a browser has seen the HSTS header, it rewrites HTTP to HTTPS internally before anything leaves the device, on every subsequent visit.
Do I need to preserve the path and query string in the redirect?
Yes — a correct redirect points to the exact equivalent HTTPS URL, path and query string intact, not a blanket redirect to the HTTPS homepage. A homepage-only redirect breaks deep links, bookmarks, and any URL with tracking parameters or specific page paths.