{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}
Paste up to 50,000 characters or load one local .htaccess, .conf, or .txt file up to 200 KB.
Browser local
{{ fileStatus }}
{{ issueFor('source_text') }}
This changes the generated wrapper only; nothing is deployed or reloaded.
Use a literal path beginning with a slash and containing no spaces.
{{ issueFor('location_path') }}
{{ annotate_source_lines ? 'Include inert annotations' : 'No extra annotations' }}
The neutral default is off. Annotations never change conversion decisions or activate additional directives.
{{ computation.values.nginx_config_draft }}
LineApache sourceDecisionReview noteCopy
{{ row.line }} {{ row.source }} {{ findingLabel(row.kind) }} {{ row.message }}
.htaccess Generator Build an Apache .htaccess draft with routing, caching, headers, and access rules plus warnings to resolve before server testing.
Nginx Server Block Generator Generate an NGINX server block for static sites, PHP-FPM apps, or reverse proxies with TLS routing plus safety and activation checks.
Apache Virtual Host Generator Draft an Apache virtual host for static files, PHP-FPM applications, or reverse proxies with TLS safeguards and activation checks.
NGINX Proxy Headers Checker Audit an NGINX proxy block for unsafe forwarded headers and trust-boundary gaps with checks for WebSocket, timeout and upstream TLS risks.

Apache and NGINX do not share one configuration language or one request-processing model. An Apache .htaccess file applies distributed rules inside a directory and can be read during request handling. NGINX reads centralized configuration at startup or reload, with directives placed in explicit http, server, and location contexts.

That architectural difference prevents a universal line-for-line conversion. An Apache rewrite pattern in .htaccess sees a path with its directory prefix removed and normally no leading slash. An NGINX rewrite pattern sees a URI beginning with a slash. Conditions, rule ordering, internal redirects, access inheritance, module guards, and query-string behavior can also change the outcome.

Placement changes the assumptions around every directive. Apache behavior depends on the directory containing the file, enabled modules, and AllowOverride. NGINX behavior depends on the selected server or location, surrounding includes, and the order in which locations and rewrite directives are evaluated.

Conditions widen the gap. RewriteCond can inspect files, headers, variables, and expressions. The closest NGINX design may use try_files, a separate server or location, map, return, or carefully reviewed rewrite logic. Choosing among them requires deployment context that source lines alone do not provide.

Safe conversion is therefore a review exercise. A small declared subset can be translated when the semantics are narrow and recognizable. Rules outside that subset should remain inert and visible rather than being turned into plausible-looking NGINX directives that may redirect the wrong requests, expose files, or create a loop.

The generated text is a draft for an existing server design. It cannot know the live document root, included files, neighboring locations, upstream services, authorization policy, or default-server behavior. Syntax testing and request tests against the complete configuration are required before reload.

How to Use This Tool:

Convert one bounded ruleset, decide where it belongs, and resolve every review or unsupported line before testing a complete NGINX configuration.

  1. Paste the .htaccess source or load a local text file. Keep the rules in their original order and include nearby comments that explain intent.
  2. Choose Output placement. Select Location block to wrap the draft in a new location, or Existing server block snippet when the directives will be merged into a server block you already maintain.
  3. For a new location block, enter a literal Location path beginning with /. The path defines the NGINX scope; it is not inferred from the filesystem location of the original file.
  4. Enable Source-line annotations only when comments will help review. Annotations do not convert extra directives or change any decision.
  5. Read the line review before copying the draft. Resolve every Review item and manually rewrite every Unsupported line using the surrounding server design.
  6. Place the reviewed text in a staging configuration, run nginx -t against the complete loaded config, then test redirects, files, directory indexes, errors, access rules, and application routes before any production reload.

Interpreting Results:

The Converted count covers lines that fit a narrow mapping. Review means a directive was emitted or deliberately omitted but its behavior depends on surrounding configuration. Unsupported means no active NGINX directive was generated; the source line appears as an inert review comment.

A high converted count does not make the draft deployable. One unsupported authorization rule or one rewrite whose location context changed can matter more than dozens of simple redirects. Read the source line, decision, and review note together.

The final check is behavioral. Use representative requests for existing files, missing paths, query strings, redirects, protected paths, and error responses. Confirm both status codes and destinations, and watch the NGINX error log for rewrite or internal redirection cycles.

Technical Details:

Each non-empty source line is parsed as a directive name plus arguments. Comments remain comments. Supported directives pass through an ordered decision set; unsupported syntax produces a comment beginning with REVIEW so it cannot become active by accident.

Rule Core:

Apache input Declared conversion Boundary
RewriteEngine On No active directive; recorded for review. NGINX rewrite directives are active when present.
RewriteCond %{REQUEST_FILENAME} !-f and !-d followed by a PHP front-controller rule try_files $uri $uri/ ... Only the exact paired file and directory exclusions with a supported PHP target are recognized.
Unconditional anchored RewriteRule NGINX rewrite with a leading slash added to the pattern. Only supported flags L, END, QSA, NC, R, R=301, and R=302; internal rewrites remain review items.
Redirect, RedirectPermanent, or RedirectTemp Prefix-matching rewrite with a 301 or 302 action. Literal source paths and simple local or HTTP targets only.
DirectoryIndex index Literal filenames only.
Options +Indexes or -Indexes autoindex on or off Enabling directory listing is always marked for review.
ErrorDocument error_page Only 3xx to 5xx status codes with a local URI.
Require all granted or denied allow all or deny all Authorization inheritance and ordering still require review.
Allow from all or Deny from all allow all or deny all Only the all-address form is supported.
IfModule guards and every other directive Inert review comment. No equivalent is guessed.

Transformation Core:

For an ordinary per-directory rewrite, a source pattern such as ^old/(.*)$ becomes ^/old/(.*)$ because NGINX matches the leading slash that Apache removes in .htaccess context. A relative replacement receives a leading slash. Redirect flags map to permanent for 301 or redirect for 302; an internal rewrite uses last and is marked for review when location re-selection or loops may change behavior.

A common PHP front-controller sequence receives a narrower conversion. Two unflagged conditions excluding existing files and directories, followed by a supported rule to a PHP target, become try_files $uri $uri/ /index.php?$query_string;. Other RewriteCond sequences remain inert because translating them to NGINX if logic would not preserve general Apache semantics.

Validation Boundaries:

  • Source text is limited to 50,000 characters and 1,000 lines.
  • A loaded local file is limited to 200,000 bytes before decoded text is checked against the character and line limits.
  • A generated location path must begin with /, contain only letters, digits, dots, underscores, tildes, slashes, or hyphens, and stay within 120 characters.
  • Control characters in review excerpts are replaced so they cannot hide inside generated comments.
  • Source annotations affect comments only; they never activate a directive or widen the supported subset.

Limitations and Security Notes:

No generated draft can account for every include file, inherited directive, default server, document root, upstream, module, or operating-system permission. Authentication rules, proxy behavior, header logic, complex conditions, environment variables, and module-specific directives need manual migration.

Conversion occurs in the browser and source text is not uploaded for processing. Treat the output as untrusted configuration until a qualified administrator reviews it, nginx -t passes on the target host, and staging requests prove the intended behavior. Do not reload a production server directly from generated text.

References: