.htaccess to Nginx Converter
Convert Apache .htaccess rules to nginx server block syntax — RewriteRule, RewriteCond, redirects, and more
Nginx config will appear here…About this tool
The .htaccess to Nginx Converter translates Apache's .htaccess directives into nginx server block syntax — RewriteRule and RewriteCond chains, Redirect/RedirectMatch, ErrorDocument, DirectoryIndex, Options -Indexes, <Files> blocks, and basic auth. It's built to get the handful of patterns that account for most real .htaccess files right, rather than attempting a mechanical, line-for-line translation that produces subtly broken nginx config. That matters most for a few extremely common idioms that don't translate literally: forcing HTTPS, stripping or adding a www prefix, and the standard WordPress front-controller block. All three involve RewriteCond capture groups interacting with RewriteRule's own capture groups in ways that collide if translated naively — this tool handles those cases specifically, and for the WordPress pattern emits nginx's own recommended `try_files` idiom rather than an if-based port, since nginx's documentation itself favors try_files over if-based file-existence checks for exactly this scenario. Anything it doesn't have a confident translation for — a specific PHP handler directive, an unusual flag combination, RewriteBase — is called out explicitly as a warning rather than silently dropped or guessed at, so you know exactly what still needs manual attention.
When to use it
- →Migrating a WordPress or PHP site's .htaccess rules when moving from Apache to nginx
- →Converting a force-HTTPS or www-redirect rule without hand-translating the regex capture groups
- →Getting a starting nginx config from an inherited .htaccess file with unclear history
- →Checking which .htaccess directives have no direct nginx equivalent before a server migration
Tips
- ◆The WordPress front-controller pattern (RewriteCond !-f, !-d, then a catch-all RewriteRule to index.php) is detected and converted to nginx's recommended try_files block — the standard, idiomatic form rather than a literal port.
- ◆Review every warning the tool surfaces before deploying — they mark directives Apache and nginx handle fundamentally differently, not just cosmetic differences.
- ◆PHP handling in nginx requires a dedicated `location ~ \.php$` block passing requests to php-fpm — there's no direct equivalent to Apache's AddHandler, so the tool provides a starting template rather than a false translation.
Frequently asked questions
Will this produce a 100% working nginx config from any .htaccess file?
For the common cases — redirects, rewrites, error pages, directory index, basic auth, simple <Files> blocks — yes, with correct handling of the tricky capture-group interactions in host/scheme redirects. For anything unusual, the tool flags it as needing manual review rather than guessing, since a confidently wrong nginx directive is worse than an honest gap.
Why can't nginx's if directive just be a direct swap for RewriteCond?
Apache chains multiple RewriteCond lines with implicit AND logic before a RewriteRule, and each cond's capture groups (%1, %2) are available to the rule's target. nginx's if doesn't chain the same way, and capture groups from a regex condition and from a rewrite pattern in the same scope can collide under the same $1 numbering — this tool handles the common single-condition cases correctly and flags multi-condition chains for manual review.
Why does the WordPress rule get converted to try_files instead of an if block?
nginx's own documentation explicitly recommends try_files over if-based file-existence checks for exactly this "serve the file if it exists, otherwise route to index.php" pattern — it's both more efficient and avoids nginx's well-documented if-directive quirks. Converting to the idiomatic form is more useful than a literal, more fragile port of the Apache logic.