Redirect Regex Tester
Test a redirect pattern against a real URL and see how the WordPress Redirection plugin, Apache and Nginx would each read it.
Your details
Match results
Pattern: ^/blog/([^/]+)$
Test path: /blog/how-to-price-a-product
Matched: yes
Groups: $1=how-to-price-a-product
Result path: /guides/how-to-price-a-product
How each engine typically reads this:
- WordPress Redirection plugin (regex mode): matches the same way as above (its engine is PCRE, close to JavaScript's for common patterns). Backreferences in the target use $1, $2…
- Apache mod_rewrite (RewriteRule): also PCRE. In a .htaccess file the pattern is matched against the URL path **without** the leading slash, so "^blog/([^/]+)$" is the version to use there. Backreferences use $1 in the target.
- Nginx (location ~ or rewrite): matches the full request path, leading slash included, same as tested above. Backreferences also use $1.This runs your pattern with JavaScript's regex engine, which covers the same ground as PCRE (used by PHP, Apache and Nginx) for ordinary patterns: groups, quantifiers, character classes, anchors. Advanced PCRE-only features like lookbehind assertions or named groups can behave slightly differently, so double-check anything unusual on the live server.
Apache's RewriteRule normally sees the path without its leading slash (outside a vhost's <Directory> context). Nginx's location and rewrite directives see the full path. That's the main practical difference once the regex itself matches.
One regex flavor, three tools
Apache's mod_rewrite, Nginx and PHP-based plugins like Redirection all use PCRE-compatible regular expressions, the same family JavaScript's regex engine belongs to, so a pattern that matches here almost always matches on the live server too for ordinary patterns (groups, quantifiers, character classes, anchors). This tool runs your pattern against a test path with JavaScript's engine and shows the match, the capture groups, and the resulting path.
The practical difference between engines is less about regex syntax and more about what part of the URL they see: Apache's RewriteRule usually matches the path without its leading slash, while Nginx's location and rewrite directives, and the Redirection plugin, match the full path including the slash.
Using the result
- Copy the matched pattern into the Nginx redirect generator or permalink redirect builder once it's confirmed.
- For Apache, remember to drop the leading slash from the pattern (the tool shows the adjusted version).
- Always test the rule on the live server afterward: advanced PCRE-only features (lookbehind, named groups) can behave slightly differently than JavaScript's engine.
Questions people ask
Does this test my rule on the live server?
No, it's a sandbox that runs your pattern with JavaScript's regex engine to check the logic before you touch a config file or plugin setting.
Why does the Apache version look different from what I typed?
Apache's RewriteRule typically matches the URL path without its leading slash, so the tool shows the adjusted pattern for that context.
Can I test WordPress's Redirection plugin rules here?
Yes, Redirection's regex mode uses a PCRE-compatible engine close enough to JavaScript's for ordinary patterns, so the match result here is a reliable preview.
What if my pattern doesn't match?
Check the test path is exactly what your redirect rule would see (with or without a leading slash, with or without a trailing one), and check for typos in character classes like [^/]+.
Related tools
Last reviewed 30 September 2026.
Sources: Apache docs: mod_rewrite · Nginx docs: ngx_http_rewrite_module (return, rewrite)
