.htaccess Redirect Generator

Build a correct Apache redirect — a single URL, www canonicalization, forced HTTPS, or a custom RewriteRule — with the condition ordering that keeps them from fighting each other.

Apache gives you two different tools for redirects, and picking the wrong one is the source of a lot of confused .htaccess files. Redirect (and RedirectMatch) come from mod_alias and handle one literal path or a single regex in one line — simple, but with no concept of conditions. RewriteRule, from mod_rewrite, is a full pattern-matching engine that can inspect the request with RewriteCond before deciding what to do. Use Redirect for a single known URL; reach for RewriteRule the moment you need a condition, like checking the host or the protocol.

Ordering inside a rewrite block is not a style preference, it changes behavior. A RewriteCond only applies to the RewriteRule that immediately follows it — it is not a global filter. That is exactly why the www and HTTPS blocks in this tool are self-contained cond-then-rule pairs rather than one shared condition list, and why HTTPS is checked before www: if you canonicalize the host first and force HTTPS second, a request can bounce through an extra pointless redirect, or in a worse case, loop, because each rule only sees the request as it existed when Apache reached that line.

The [L] flag is one of the most misunderstood parts of mod_rewrite. It does not mean “stop processing this request” — it means “stop processing rules in this pass and restart matching from the top of the ruleset with the URL as rewritten so far.” For an internal rewrite (no redirect), that restart is invisible to the visitor and just costs a little extra rule evaluation. For an external redirect like R=301, the browser makes a whole new HTTP request, which is why chaining several redirect rules together can mean several visible round trips.

301 versus 302 is not just semantics, it is a caching decision. A 301 tells browsers and CDNs “this is permanent, stop asking” and they cache it, sometimes for a very long time — which is exactly what you want once a move is final, and exactly what makes a wrong 301 painful to undo, since visitors and search engines keep using the stale cached redirect long after you fix it. A 302 is not cached the same way, which makes it the safer choice while you are still testing that a redirect target is correct.

%{HTTPS} and %{HTTP_HOST} are server variables, not something you set — Apache populates them per request. %{HTTPS} is on or off depending on whether TLS terminated the connection; if your site sits behind a load balancer or reverse proxy that terminates TLS upstream, %{HTTPS} can read off even for a genuinely secure visitor, and you need %{HTTP:X-Forwarded-Proto} instead — a common cause of infinite redirect loops on proxied setups.

A missing RewriteEngine On is the single most common reason a freshly pasted rule block silently does nothing: every directive after it is simply ignored without an error. It only needs to appear once per .htaccess file, so if you are adding a second block to a file that already has rules, drop the duplicate this tool includes.