GenerateRandomSearch

htaccess Redirect Generator

A redirect rule that compiles and sends visitors to the wrong place is the failure people actually ship, because nothing complains — the server does exactly what the rule says. So every rule generated here is applied to an example path and the result is written above it as a comment, and the page checks that the rule really does send that path where the comment claims. The status codes are on every line too: a 301 is cached by browsers for a very long time and is hard to take back.

What this generator does

Writes a RewriteEngine block of one to six rules, each with a capture group carried into its target, an example path in a comment above it, and an explicit redirect status. Every rule is then applied to its example path and the result compared with the comment.

How to use this tool

  1. Choose how many redirects you want.
  2. Generate, and read the example path above each rule.
  3. Check the verification note.
  4. Adapt the patterns to your own paths, keeping the example comments up to date.

Understanding the controls

How many redirects
One to six. Each is a different pattern, so the block shows several shapes of rule rather than one repeated.

Worked examples

One generated rule and its comment
RewriteRule ^docs/v1/(.*)$ /docs/v2/$1 [R=302,L] with the comment "/docs/v1/case-study -> /docs/v2/case-study" above it — the captured text (case-study) is the one quantity shared between the example path and the rule's own substitution, so neither was built by editing the other.

Common use cases

  • Starting a redirect block after a site restructure
  • Showing the difference between a permanent and a temporary redirect
  • Producing fixtures for something that parses rewrite rules
  • Teaching how a capture group is carried into the target
  • Checking your own rules against a working example of the same shape

How this generator works

Each rule keeps the captured text as the shared quantity: the example path and the target are both built from it, so neither is derived from the other by string surgery. The check compiles the pattern, matches it against the example, substitutes the capture into the target the way the server would, and compares. An earlier version built the example by editing the pattern text and produced a target ending “.zip.zip” — the check caught it, because it applies the rule rather than repeating the arithmetic that made it.

Randomness and fairness

Which patterns appear, the captured slugs and the choice between 301 and 302 are drawn with your browser's cryptographic random source.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

  • Apache RewriteRule syntax only — nginx, Caddy and IIS all express redirects differently.
  • No conditions: RewriteCond, host matching, query strings and HTTPS enforcement are all out of scope here.
  • The patterns are examples of common shapes rather than rules for your site, and the paths in them are invented.
  • The check confirms each rule lands where it claims, not that the destination exists on your server.
  • A 301 is cached hard by browsers. Test with a 302 first — the generated rules use both for that reason, about one in four being a 302.

Privacy and your data

Rules are generated in your browser from built-in patterns. You enter nothing, nothing is uploaded or stored, and analytics records only that the tool ran and how many rules were made.

Frequently asked questions

Should I use 301 or 302 while testing a new redirect?
302 (temporary) while you're still confirming the rule does what you intend — browsers and search engines cache a 301 (permanent) aggressively, sometimes for months, so a mistake shipped as a 301 can keep sending visitors to the wrong place long after you fix the rule. Switch to 301 only once you're confident the redirect is correct and permanent.
How does the capture group in the pattern reach the target URL?
The parentheses in a pattern like ^docs/v1/(.*)$ capture whatever text matches inside them, and $1 in the target refers back to that captured text — so a request for docs/v1/case-study captures "case-study" and the rule rewrites it into docs/v2/case-study. This is what lets one rule redirect an entire section of a site rather than one URL at a time.