.htaccess Validator: Catch Syntax Mistakes Before They Break Your Site
Apache re-reads .htaccess on every request, and a single malformed directive typically takes down the entire site with a 500 error — not just the feature you were editing. This validator checks your rewrite rules, redirects, error documents, and block tag nesting against common Apache syntax rules before you upload the file.
RewriteCond needs a test-string and a condition-pattern; block tags like <IfModule> must be properly closed.
Why a Small Typo Takes Down the Whole Site
Unlike application code, .htaccess is parsed by the web server itself on every single request to that directory. If the syntax is invalid, Apache doesn't just skip the broken line — it typically refuses to serve any request under that directory at all, returning a 500 Internal Server Error until the file is fixed.
Common RewriteRule Mistakes
A RewriteRule needs at minimum a pattern and a substitution target; forgetting one turns a rewrite rule into a fragment Apache can't parse. Flags in square brackets (like [R=301,L]) also have a fixed, known set — a typo'd flag name is silently ignored by some Apache versions or rejected outright by others, depending on configuration.
Legacy vs. Modern Access Control
Apache 2.2's Order/Allow/Deny directives were replaced in Apache 2.4 by the Require directive from mod_authz_core. Most current hosting environments run Apache 2.4, so 'Order allow,deny' + 'Allow from all' should generally be modernized to 'Require all granted' for a setup that matches your actual server version.
Practical Examples
Catching an Unclosed Block
A missing closing tag.
- 1.
- 2. ExpiresActive On
- 3.(missing )
- 4.Error:
opened here is never closed.
Flagging a Malformed RewriteCond
Missing the condition pattern.
- 1.RewriteCond %{HTTPS}
- 2.Error: RewriteCond needs at least 2 arguments, found 1
- 3.Fix: RewriteCond %{HTTPS} off
What Gets Checked
- Block tag nesting: <IfModule>, <Files>, <Directory>, etc.
- RewriteRule/RewriteCond: minimum argument count
- RewriteRule flags: recognized mod_rewrite flags
- ErrorDocument: valid 3-digit status code
- Legacy syntax: Order/Allow/Deny vs. Require
Good Use Cases
- Reviewing a .htaccess file before uploading to a shared host
- Debugging a mysterious 500 error after an edit
- Modernizing an old Apache 2.2-style config
- Learning mod_rewrite syntax with immediate feedback
Frequently Asked Questions
Why is a broken .htaccess so risky?
Apache reads .htaccess on every request in the directory it applies to. A single syntax error there commonly returns a 500 Internal Server Error for your entire site, not just the broken feature — which is why catching mistakes before uploading matters.
What does it check for RewriteRule and RewriteCond?
That each has the minimum required arguments (a pattern and a target for RewriteRule; a test string and condition for RewriteCond), and that any RewriteRule flags (like [R=301,L]) match common, recognized mod_rewrite flags.
Why does it flag 'Order allow,deny' and 'Allow from all'?
That's Apache 2.2's access-control syntax. Apache 2.4 (the current version on virtually all modern hosts) replaced it with mod_authz_core's 'Require' directives — 'Require all granted' instead of 'Order allow,deny' + 'Allow from all'. The old syntax still works in compatibility mode on some setups but is considered legacy.
How does it check block tags like <IfModule>?
It tracks a stack of opened tags and matches every closing tag against the most recently opened one, the same way an XML/HTML validator checks nesting — flagging unclosed blocks and mismatched close tags.
Does this check whether a referenced module (like mod_rewrite) is actually enabled on my server?
No — that's server configuration this tool has no visibility into. It only validates the .htaccess file's own syntax.
Is my .htaccess file uploaded anywhere?
No, validation runs entirely in your browser via text parsing — no server access, no upload.