.htaccess to Nginx Converter - Convert Apache Rules

How to convert .htaccess to Nginx

1. Add your Apache rules

   Paste your .htaccess text or select a UTF-8 .htaccess, .conf or .txt file. Keep an unchanged backup of the original.

2. Convert and review

   Choose whether to add a server wrapper and comments, then click Convert to Nginx. Read the line-by-line notes for anything that needs manual conversion.

3. Copy, test and reload

   Copy the draft or download nginx.conf. Merge it into your server configuration, test with nginx -t, then reload only after checking the result.

Practical uses for this converter

What gets converted

Why Nginx has no .htaccess file

Nginx does not read per-directory .htaccess files. Its routing and access rules belong in the central configuration, usually inside a server block and its location blocks. Moving a .htaccess file into your document root will not activate those rules.

The optional server wrapper is a starting container, not a complete hosting configuration. Set your real listen, server_name and root, and configure TLS or application upstreams separately. Do not nest a generated server block inside an existing one.

After editing the actual configuration, run nginx -t to check syntax and referenced files. Reload Nginx only when the check succeeds, using your system's service command or nginx -s reload. Also test real requests: a syntax check does not prove that routing or access control is correct.

Apache and Nginx examples

These are hand-written migration examples, not a promise that every equivalent Apache input is automatically recognized. Replace example.com and merge each snippet into the right context.

WordPress front controller

A typical Apache setup sends requests for nonexistent files and directories to index.php.

Before - Apache .htaccess

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

After - inside an Nginx server block

location / {
    try_files $uri $uri/ /index.php?$args;
}

Configure a separate, secure PHP handler and the correct document root. This snippet does not configure PHP-FPM, multisite, caching or security restrictions.

Redirect HTTP to HTTPS

Before - Apache .htaccess

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

After - dedicated Nginx HTTP server block

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

The HTTPS destination still needs its own TLS-enabled server block and certificate. Behind a proxy, check where TLS terminates before adding scheme-based redirects.

Redirect www to the preferred hostname

Before - Apache .htaccess

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

After - Nginx hostname redirect

server {
    listen 80;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

This block handles HTTP only. Redirecting requests received at https://www.example.com also requires a TLS listener and a certificate valid for www.example.com.

Conversion limitations and safety checks

Apache per-directory rewrites match a path relative to the directory, often without a leading slash. Nginx server rewrites and location matching use different contexts. Rules copied from a nested .htaccess need their path prefix and document root checked manually.

Regular expressions, escaping, backreferences, query strings and rewrite flags can behave differently. The converter does not execute your patterns or simulate HTTP requests. A pattern that looks familiar is not proof of equivalent routing.

Multiple RewriteCond lines are converted using flag variables: consecutive OR conditions form a group, and groups are joined with AND, including the RewriteRule path pattern. A final OR flag is ignored. Single simple conditions use a compact if. Mixed file tests are supported; aliases and filesystem paths still need review.

Condition backreferences such as %1 are converted only from the last capturing condition of an AND-only chain. OR-group backreferences and other ambiguous captures are not converted. Rule backreferences such as $1 use named captures where condition regexes could overwrite Nginx's numbered captures.

CodeIgniter-style index.php/$1 routes use try_files with PATH_INFO. The PHP location needs fastcgi_split_path_info ^(.+\.php)(/.+)$; and fastcgi_param PATH_INFO $fastcgi_path_info;. Query-style index.php?url=$1 routes use a named location to preserve the path without its leading slash.

Nginx's often-cited "if is evil" warning concerns unsafe uses of the rewrite module's if inside location contexts. It does not mean all uses of if are forbidden. Prefer a structure you can reason about, and inspect generated conditionals instead of treating them as a universal Apache translation.

Authentication, module-specific sections, access controls and complex rewrite chains can require manual work. A skipped rule is not automatically safe to remove. Review every note, run nginx -t, and test redirects, query strings, missing files and protected resources in a staging environment before changing a live service.

Input is limited to 1,048,576 UTF-8 bytes. The main-thread parser can still pause the interface on complex input; there is no execution-time guarantee. The visible notes list shows at most 500 entries and shortens long entries; the notes download includes the full list.

Related tools

Regex Tester helps explore patterns on sample paths; its regex behavior is not a substitute for testing Apache or Nginx.

JSON to TypeScript generates declaration drafts from JSON samples when you are also migrating application code.

HTML Minifier reduces HTML markup after you have checked that your migrated site serves the right pages.