A redirect rule tester lets you paste your Apache .htaccess or nginx rewrite rules, type in a test URL, and instantly see which rule fires, the URL it produces, and the HTTP status code — without deploying anything. The tool above evaluates the rules top to bottom, just like a real server, and prints a step-by-step trace so you can see exactly where a request lands. Everything runs in your browser; nothing you paste is sent anywhere.
What this tool does
Redirects are easy to get subtly wrong. A pattern that looks right can match too much, sit below a broader rule that swallows the request first, or fire with the wrong status code. Normally you only find out after pushing to production and watching the logs. This tester closes that loop locally: give it your rules and a path, and it walks the list in order, reports each rule as a hit or a miss, and shows the final destination and status.
Supported rule types
The tester covers the patterns you reach for most often on both servers:
| Server | Directive | Example |
|---|---|---|
| Apache | RewriteRule | RewriteRule ^old/(.*)$ /new/$1 [R=301,L] |
| Apache | Redirect | Redirect 301 /legacy /modern |
| Apache | RedirectMatch | RedirectMatch 302 ^/promo/(.*)$ /deals/$1 |
| nginx | rewrite | rewrite ^/team/(.*)$ /about/$1 permanent; |
| nginx | return | return 301 https://example.com$request_uri; |
| nginx | location | location = /contact { return 301 /contact-us; } |
Regular-expression back-references ($1, $2 and so on) are substituted into the target, so capturing groups behave the way they do on the server.
Redirect versus internal rewrite
The single most useful distinction this tool makes clear is between a redirect and an internal rewrite. A redirect returns a 3xx status to the browser, which then fetches the new URL — the visitor sees the address bar change. An internal rewrite (a RewriteRule with no R flag, or an nginx rewrite ... last) silently maps the request to a different file on disk; the response is an ordinary 200 and the URL never changes. Mixing these up is a common source of confusion, so the trace labels each outcome explicitly.
A worked example
Suppose you paste these Apache rules and test the path /blog/2024/hello-world:
RewriteRule ^old-page.html$ /new-page.html [R=301,L]
RewriteRule ^blog/([0-9]+)/([^/]+)$ /posts/$2 [R=301,L]
Redirect 301 /legacy /modernThe first rule is checked and does not match. The second matches: the year is captured but discarded, the slug hello-world is pulled into $2, and the result is a 301 redirect to /posts/hello-world. Because the rule carries the L flag, evaluation stops there and the third rule is never reached. The trace shows all of this at a glance.
Common redirect mistakes it helps catch
- Order conflicts — a broad rule placed above a specific one intercepts requests before the specific rule runs.
- Wrong status code — using a 302 where you meant a permanent 301, which quietly costs you SEO signals.
- Leading-slash surprises — Apache strips the leading slash for per-directory RewriteRule matching, so
^/blogoften never matches. - Greedy patterns —
(.*)capturing more than intended and building a broken target URL. - Missing the L flag — expecting a rule to be final when later rules keep rewriting the path.
Honest limits
This is a pattern simulator, not a byte-for-byte reimplementation of Apache or nginx. It does not evaluate RewriteCond guard conditions, query-string flags such as QSA, server variables like %{HTTP_HOST}, virtual-host or server-block context, or proxy passes. Rules that depend on those features may match differently in production. Use the tester to sanity-check ordering, capturing groups and status codes, then confirm anything critical against a staging server. Because the whole thing runs locally in your browser, it is safe to paste rules from private configuration files, and it keeps working even if you disconnect from the network.