Free .htaccess Rule Tester

The .htaccess Rule Tester is a free online tool that test .htaccess rewriterules and redirects. step-by-step rule evaluation for any url. It runs entirely in your browser with no installation or sign-up needed.

RewriteRule, RewriteCond, Redirect, RedirectMatch, and Header directives.

Yes — step-by-step evaluation shows which conditions were met or skipped.

Yes, completely free.

Absolutely. The .htaccess Rule Tester processes everything client-side in your browser. No data is uploaded to or stored on any server. Your content remains private on your device at all times.

Yes, the .htaccess Rule Tester is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the .htaccess Rule Tester in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

The .htaccess Rule Tester works in all modern browsers including Chrome, Firefox, Safari, Edge, and Opera. For the best experience, use the latest version of your preferred browser.

In an .htaccess RewriteRule, the flag [R=301] issues a permanent redirect and [R=302] issues a temporary one — and the choice matters for SEO. A 301 tells search engines the move is permanent, so they transfer ranking signals from the old URL to the new one and update their index. A 302 signals the original URL will return, so engines keep indexing the old address and may not pass authority along. The common mistake is leaving the default, since a bare [R] flag resolves to 302. Use 301 for renamed pages, www or HTTPS canonicalization, and retired URLs; reserve 302 for genuinely short-lived moves like maintenance pages. Paste your rules above with a test URL and the tester reports the exact HTTP status each redirect would return, so you can confirm it says 301 before you ship it.

The [L] flag means "last": when a RewriteRule with [L] matches, Apache stops processing the remaining rewrite rules in that round and uses the result. Because Apache evaluates rules top to bottom in sequence, the order of your rules changes the outcome as much as the rules themselves. A broad rule placed early can match and halt before a more specific rule below ever runs, or a missing [L] can let several rules fire in a chain and produce a URL you never intended. This is one of the hardest things to reason about by reading raw text. The tester walks your rules in the same top-to-bottom order Apache uses and marks exactly where [L] stops processing, so you can see whether a rule is short-circuiting the ones beneath it before going live.

The most common reason is the leading slash. In a per-directory .htaccess file, the path Apache hands to your RewriteRule pattern has the leading slash already stripped, so a pattern like ^/old-page will never match — you want ^old-page instead. Other frequent culprits are an unescaped dot (use \. for a literal period), a greedy pattern such as (.*) catching more than intended, a RewriteCond above the rule that quietly fails so the rule is skipped, or RewriteEngine never being switched On. Regex anchors matter too: ^ and $ pin the start and end of the path. The step-by-step trace here shows the value being compared against your pattern and a plain-English note saying whether it matched or was skipped and why, which usually pinpoints the mismatch in seconds. Paste the rule and a sample path to check it.

A redirect loop happens when a rule keeps rewriting a URL to a target that matches the same rule again, so the browser bounces endlessly and shows an ERR_TOO_MANY_REDIRECTS error. Typical causes are an HTTPS-forcing rule whose condition never becomes satisfied behind a proxy, a www rule that re-triggers on its own output, or two rules that point at each other. The fix is usually a tighter RewriteCond that excludes the already-correct state — for example only redirecting when %{HTTPS} is off — plus a proper [L] flag to stop further processing. Reading rules statically rarely reveals a loop. Run your snippet against a test URL in the tester and watch the trace: if the output URL would re-enter the same matching rule, the step-by-step evaluation makes that chain visible so you can break it before deploying.

Not reliably, and that is by design. Conditions such as RewriteCond %{REQUEST_FILENAME} !-f or -d ask Apache whether a real file or directory exists on disk, and a browser has no access to your server's filesystem. So the tester approximates them: file and directory existence tests resolve to false, and %{REQUEST_FILENAME} is stood in with the request path rather than a true filesystem path. That means logic depending on -f, -d, or -e — common in front-controller setups that route missing files to index.php — will not behave exactly as it does on Apache. The tool is built to validate the logic, ordering, and flags of your rewrite and redirect rules quickly and privately. Use it to confirm patterns, capture groups, status codes, and [L] behaviour here, then verify anything filesystem-dependent on your actual server before going live.