.htaccess Syntax Checker
Paste the contents of an .htaccess file to instantly catch common mistakes: unclosed block tags, misspelled directive names, RewriteRule with too few arguments, and dangling RewriteCond lines.
Tips
- This checker is a heuristic, line-based static analysis — it is not a real Apache parser. Always test on a real server or staging environment before deploying.
- If you have shell access to the Apache server,
apachectl configtestis the most authoritative syntax check available. This tool is meant for quick pre-checks when that command is not accessible, such as on shared hosting. - The unrecognized-directive warning is a low-confidence guess based on a fixed allowlist. If you use a directive from a less common module, seeing this warning does not necessarily mean it is wrong.
- Stacking several RewriteCond lines in a row is normal usage (they act like AND conditions). This tool only warns when the very last RewriteCond in a chain is not followed by a RewriteRule.
- Before uploading to production, apply changes incrementally and verify each step, rather than pushing a large rewritten file all at once.
Frequently Asked Questions
AllowOverride None set for that directory, meaning .htaccess is ignored entirely. Ask your server administrator to confirm AllowOverride All (or at least the specific override categories you need, such as AuthConfig or FileInfo) is enabled. It is also worth checking whether a browser or CDN cache is serving a stale response.RewriteRule pattern substitution [flags]. The pattern is a regular expression matched against the requested URL path (without the leading slash), and the substitution can reference capture groups from the pattern using $1, $2, and so on. Flags go in square brackets, comma-separated, such as [L] (stop processing further rules) or [R=301] (permanent redirect).%{REQUEST_FILENAME} !-f (only apply the rule if the path is not already an existing file) so the rule stops once the target actually exists.
Side Note — Why is it called ".htaccess"?
The name ".htaccess" is short for "hypertext access", and its history traces back to the early versions of NCSA httpd and Apache around 1995. It was originally introduced to let directory owners configure password protection (Basic authentication) for their own space without needing to touch the server-wide configuration file (httpd.conf), which only the server administrator could edit.
What makes .htaccess powerful is that, as long as the Apache administrator has permitted it via the AllowOverride directive, changes take effect the moment the file is uploaded via FTP or a file manager — no server restart required. This lets users on shared hosting, who typically have no access to the main server configuration, control redirects, caching, and access restrictions on a per-directory basis.
That convenience comes at a cost, though. Apache's own documentation explicitly recommends putting directives in the main server configuration instead of .htaccess whenever you have access to do so. The reason is simple: Apache has to search for and re-read .htaccess files in every parent directory on every single request, which introduces a non-trivial performance overhead compared to configuration baked into the main config file.
A stray syntax error can also be costly: on many shared hosting setups, an invalid .htaccess turns every page under that directory into a blank "500 Internal Server Error", and tracking down the exact cause can eat up a surprising amount of time. Running a quick static check like this one, in addition to a careful read-through, helps catch careless mistakes before they cause an outage after deployment.