How to Redirect HTTP to HTTPS with .htaccess

Make the secure address the destination

An HTTP-to-HTTPS redirect tells a browser to request the secure version of a resource. It does not create a certificate or configure encryption on the destination server. Before changing redirects, open the intended HTTPS address directly and confirm that the certificate and website work for every hostname people may use.

For Knut-Edvart.com, the preferred destination is https://www.knut-edvart.com. Keeping both the secure scheme and preferred hostname in one rule can avoid a chain such as HTTP without www, HTTPS without www, then HTTPS with www. The goal is a predictable final address with the original path and meaningful query string intact.

Check where the redirect belongs

If you control Apache’s virtual-host configuration, a dedicated HTTP virtual host is often the clearest place to redirect insecure traffic. Apache’s documentation recommends that approach for the common case. Shared hosting may instead provide a control-panel setting or allow rules in a document-root .htaccess file.

This article covers that last situation: Apache 2.4, mod_rewrite enabled, the required override permission granted, and TLS terminating on the same server. A CDN or reverse proxy changes what the backend can observe. Do not apply the direct-TLS example unchanged to a proxy configuration where HTTPS arrives at Apache as HTTP.

Test a temporary redirect first

Back up the existing file and merge the example above internal routing rules. Preserve unrelated access rules, application configuration and hosting-managed sections. Do not replace a working file with a tutorial snippet. These examples are downloads only; this article does not change the site’s own redirect configuration.

# EXAMPLE ONLY: Apache 2.4, TLS terminates on this server.
# Place in the document-root .htaccess, above internal routing rules.
# Test with 302 first; use 301 only after verifying the result.
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\.knut-edvart\.com$ [NC]
RewriteRule ^ https://www.knut-edvart.com%{REQUEST_URI} [R=302,L]

Download the example rules. The download uses a text extension so it cannot accidentally become an active .htaccess file. The hostname is deliberately literal. Replace it with your intended hostname when adapting the example for another site.

The first condition matches a connection that is not HTTPS. Its [OR] flag joins it to the second condition, which matches a different hostname. Therefore either an insecure request or a noncanonical host triggers the rule. A request already using HTTPS and the exact preferred hostname matches neither condition and continues normally.

RewriteRule ^ matches the start of any path in this directory context. The replacement combines the fixed secure origin with REQUEST_URI, preserving the requested path. With no new query string in the substitution, Apache normally carries the original query string forward. Do not add QSD if retaining parameters is part of your intended behavior.

Why use a fixed hostname?

Many snippets build the destination from HTTP_HOST. That value reflects incoming request information, so it is a poor default when the site has one approved public hostname. A fixed destination makes the intended result obvious and avoids reflecting an unexpected host into the Location header.

It also combines hostname normalization with the scheme upgrade. However, an HTTPS request to a bare domain still needs a certificate valid for that bare domain before a redirect can be delivered. The TLS handshake happens before Apache sends the HTTP response. Redirect rules cannot repair a certificate-name mismatch encountered first.

Understand proxy redirect loops

Suppose a CDN accepts the visitor’s HTTPS connection and forwards plain HTTP to Apache. Apache sees HTTPS as off, sends a redirect to the same public HTTPS URL, and repeats the process when the visitor follows it. The browser eventually reports too many redirects even though the rule looks correct for a direct connection.

Prefer the hosting provider’s documented HTTPS redirect setting or correctly configured trusted-proxy integration. A forwarded scheme header is meaningful only when a trusted proxy sets or overwrites it and direct untrusted access is controlled. Adding an unconditional trust in X-Forwarded-Proto is not a universal fix.

Check whether a control panel, CDN, application or existing rule already performs the same redirect. Pick an intentional owner for the behavior and remove conflicting settings only after understanding them. The desired public destination should agree across all these layers.

Inspect the response, not just the address bar

Use a header request to inspect the first response, then follow the chain with a limited redirect count. Quoting the URL keeps shell characters in the query string from being interpreted by the terminal.

curl -I 'http://knut-edvart.com/programming/php/?page=2'
curl -I -L --max-redirs 5 'http://knut-edvart.com/programming/php/?page=2'

During testing, expect a 302 response with a Location pointing to the HTTPS www version and the same path and query. Test HTTP with and without www, HTTPS without www and the final HTTPS www address. For an existing resource, the final address should return its normal response without redirecting back to itself.

Also check nested paths, filenames containing encoded characters, missing pages and any certificate-renewal challenge routes your host requires. Response handling can differ around unusual encoded paths. If your application receives form submissions or API requests, decide whether redirects are appropriate there and whether method-preserving status codes are required.

Make it permanent after verification

Once the temporary behavior is correct, change R=302 to R=301 for a permanent redirect of ordinary website navigation. Permanent redirects can be cached, so repeat testing with a fresh client and remember that reversing a cached result may take time. Keep a recovery copy of the previous configuration.

Update internal links and sitemaps to the final HTTPS address so visitors and crawlers can go there directly. Review mixed-content references separately: an HTTPS page can still contain old HTTP asset URLs. For background, see 301 vs. 302 redirects and redirecting a directory.

Document which layer owns the redirect and keep the tested rule alongside your deployment notes. That makes future hosting moves easier to diagnose, particularly when a new proxy changes how Apache sees the incoming connection.