Redirect Regex Tester

· Free browser tool

A redirect regex tester checks an Apache RewriteRule pattern against a real test path before the rule ever touches a production .htaccess file, so a regex that silently fails to match, or that captures the wrong segment, is caught while it is still a draft rather than after a live URL starts 404ing. A single greedy quantifier or a misplaced anchor is the difference between a clean 301 and a redirect loop, and the only safe way to know which you have written is to run the pattern against the path it is meant to catch.

This tool is free and runs entirely in your browser. It compiles the pattern, tests it against the path exactly the way Apache strips the leading slash and host, lists every captured group, and rebuilds the destination from the $1 backreferences in your substitution string, so nothing you paste is ever sent to a server.

Redirect Regex TesterFree · client-side
The pattern from your RewriteRule. Apache matches the path with the leading slash already stripped.
Destination with $1$9 backreferences to the captured groups.
Paste a path like /old-blog/42/my-first-post or a full URL — the host is stripped for matching.
Apache is case-sensitive unless the rule carries the [NC] flag.
Result

🔒 Private: everything runs in your browser. Nothing you paste is uploaded.

Resulting destination

    

How to use the redirect regex tester

Paste the pattern from your RewriteRule, the substitution target with its backreferences, and the path you expect a visitor to hit. The result, the captured groups, and the rebuilt destination update on every keystroke.

Match the path the way Apache actually sees it

A RewriteRule in a per-directory context never receives the scheme, host, or leading slash: Apache strips them before the pattern runs, which is why a rule that begins with ^/ almost never matches. This tester normalises the test value the same way, dropping https://example.com and the opening slash so the path that reaches the regex is the one Apache would test. Paste a full URL or a bare path and the tool shows the exact string being matched, so an anchor that works in a generic regex engine but fails on the server is exposed before deployment.

Read the captured groups before trusting the substitution

Every parenthesised group in the pattern becomes a numbered backreference, and the destination is only correct if each $1 through $9 points at the segment you intend. The tool lists all captured groups with their values, distinguishes a group that matched an empty string from one that never participated, and then rebuilds the substitution so the final destination is visible character for character. When a target references $2 but the pattern only captured one group, the rebuilt URL makes the mistake obvious instead of shipping a broken redirect.

Test the no-match and case-sensitivity edges deliberately

Most redirect bugs are not wrong destinations but rules that quietly fail to fire, so testing a path you expect to miss is as valuable as testing one you expect to catch. A clear no-match result confirms the pattern is scoped tightly and will not hijack unrelated URLs. Apache is case-sensitive by default, so toggle the case-insensitive option to model the [NC] flag and confirm that /Old-Blog/ behaves the way you assume. Verifying both the hit and the miss is what separates a tested rule from a hopeful one.

Redirect regex tester frequently asked questions

Q1Why does my RewriteRule pattern fail to match the leading slash?

In a per-directory context, such as an .htaccess file, Apache removes the leading slash from the path before the pattern runs, so a rule beginning with a caret and a slash will never match. Write the pattern against the path without its opening slash. This tester strips the slash and the host automatically, so the path you see being matched is the one Apache actually tests.

Q2What is the difference between $1 and a regex capture group here?

They are two sides of the same thing. Each parenthesised group in the pattern is captured in order, and Apache exposes those captures to the substitution string as the backreferences $1 through $9, with $0 holding the whole match. The tester lists every captured group and its value, then rebuilds the destination by substituting those backreferences, so you can confirm each one points at the segment you intended.

Q3Does this redirect tester send my rules anywhere?

No. The pattern is compiled and tested with client-side JavaScript inside your browser, and nothing you paste into the pattern, substitution, or test path fields is uploaded, logged, or stored. The tool works offline once the page has loaded, which makes it safe to use for internal paths, staging hosts, or any URL structure you would rather not expose.

Q4Is the matching case-sensitive like real Apache?

By default, yes. Apache treats RewriteRule patterns as case-sensitive unless the rule carries the NC flag, and this tester matches that behaviour out of the box. Switch the flags option to case-insensitive to model an NC flag and confirm how mixed-case paths behave. Testing both modes prevents a rule that works in lowercase from missing the uppercase variants a real visitor might request.

Q5Can I test a redirect that should not fire?

Yes, and you should. A clear no-match result is a feature, not a failure: it confirms the pattern is scoped tightly enough that it will not catch unrelated URLs and cause an unintended redirect. Paste a path you expect to miss and verify the tester reports no match. Confirming the misses is as important as confirming the hits when you are building a safe redirect map.

Hristo Bogdanov, Head of SEO at SEO Domains

Hristo Bogdanov

Head of SEO @ SEO Domains · CEO & Co-founder of SEO.bo

Hristo has spent 15+ years building aged-domain acquisition and screening workflows for SEO professionals, brand owners, and domain investors, and builds the free tooling SEO Domains publishes for practitioners.