Why are my RewriteCond rules missing from the result?

Their variables, captures, evaluation order and deployment context can change meaning, so the tool reports them instead of creating an unsafe unconditional rule.

Can I reload Nginx immediately after copying the converted lines?

No. Back up the configuration, assemble it in the correct context, run nginx -t and test on staging or behind a reversible maintenance window before issuing a reload.

Do I need to know regular expressions to use the tool?

You do not need to write them, but you should understand what your existing patterns match before you trust the converted Nginx lines. Identical-looking regexes can behave differently across the two servers.

Is my .htaccess file sent to a server?

No. The conversion happens locally in the browser and the input is not uploaded to Lizely.

htaccess to Nginx for Beginners: A Safe First Migration

Migrating an Apache .htaccess file to Nginx is a translation problem with hard limits, and a beginner-friendly approach starts by accepting that Apache's per-directory directives and Nginx's centralized configuration blocks are not interchangeable. Apache evaluates .htaccess on every request, walks down the directory tree, and applies rules scoped to each folder; Nginx reads one hierarchical configuration once, then chooses a server and location context before any rewrite runs. That difference is the reason "just convert it" does not exist as a safe operation. Beginners who treat the two formats as equivalent often end up with rewrite loops, cached redirects that point at the wrong host, or local 404 pages that never fire. A scoped converter helps with the first pass: it translates a narrow subset of directives and reports everything else with a line number so you can finish the migration by hand against the official Apache and Nginx documentation.

The Architectural Gap Between Apache .htaccess and Nginx

Apache's .htaccess is a per-directory overlay. Each request walks the path, and the server merges any AllowOverride-enabled directives it finds along the way. RewriteCond, RewriteRule, ErrorDocument, Header, Options and authentication blocks can all live inside a single folder, and changing them only requires editing a file and waiting for the next request. Nginx has no equivalent loop. It reads the configuration once at startup, picks a server block for the incoming connection, then chooses a location block for the URI. The Nginx core error_page directive and its rewrite siblings live inside those blocks; they are not rediscovered by walking the filesystem.

Three practical consequences follow. First, an Nginx rewrite pattern sees a URI that begins with a slash, while a document-root .htaccess RewriteRule usually strips that prefix. Second, Apache's RewriteCond can inspect server variables that Nginx evaluates differently or not at all. Third, conditional headers and access-control directives that Apache applies per request have no portable Nginx expression. A beginner converter can only translate a deliberately narrow subset because the rest of the surface area has to be migrated by hand.

What a Beginner Converter Should and Should Not Do

A beginner converter earns its keep by doing two things: turning the few rules that translate cleanly into Nginx lines, and pointing at everything else. It should refuse to guess. A tool that emits plausible-looking RewriteCond translations, silently drops unsupported flags, or fabricates a server block around your fragment will eventually take a site offline. Beginners in particular should look for the following behaviours before trusting any converter:

An auditable list of supported directives, not a marketing promise of "full coverage".
Line-numbered warnings that preserve the original .htaccess context.
A flag set that is intentionally small, such as L, R, R=301 and R=302, with the rest rejected.
Local processing in the browser, with no upload of the input.
Output that is explicitly a fragment rather than a full nginx.conf.

That contract matches the htaccess to Nginx Converter approach: it ignores RewriteEngine On, preserves comments, returns warnings for anything conditional or unfamiliar and never claims to finish the migration on its own.

How the htaccess to Nginx Converter Works for First-Time Users

Open the tool and paste a focused excerpt of your document-root .htaccess, not the whole file. Keep only the RewriteRule, Options, ErrorDocument and Header lines you want reviewed in this pass.
Convert only the supported directive subset. The tool emits Nginx lines for the rules that fit its narrow contract and ignores RewriteEngine On while preserving your comments.
Review every emitted line and resolve each line-numbered warning manually against the Apache mod_rewrite introduction and the Nginx documentation before copying anything into your config.
Merge the reviewed lines into the correct Nginx context — usually a server block for server-wide redirects and headers, or a location block for path-scoped rewrites — and back up the active configuration first.
Run nginx -t to validate the assembled file, then test representative requests on staging or behind a maintenance page before issuing a reload that could affect live traffic.

The loop is short on purpose. Convert, review, merge. Anything that breaks the loop — a warning you cannot resolve, a flag you do not recognize, a condition that touches HTTPS or host state — is the moment to stop and read the manuals rather than guess.

Translating Supported Directives: A Worked Walkthrough

Apache directive	What the converter does	Nginx result
RewriteRule pattern target [L]	Inserts a leading slash for the document-root pattern, preserves a backreference	rewrite ^pattern(/.*)$ /target$1 last;
RewriteRule pattern target [R=301]	Treats a permanent Apache redirect as the nginx permanent flag	rewrite ^pattern$ /target permanent;
RewriteRule pattern target [R]	Treats a temporary redirect as the nginx redirect flag	rewrite ^pattern$ /target redirect;
RewriteRule pattern target [QSA, END, F, G, B, NC]	Flags conversion for that rule and emits a warning	(no emitted line)
RewriteCond ...	Suppresses the rule that follows; conditions are not translated	(no emitted line)
RewriteRule pattern - [flags]	Withholds the no-substitution dash target	(no emitted line)
Options -Indexes	Maps directly	autoindex off;
ErrorDocument 404 /local-404.html	Maps the local 404 path	error_page 404 /local-404.html;
Header set X-Robots-Tag "value"	Maps the quoted value	add_header X-Robots-Tag "value";

Three details deserve attention. First, the supported rewrite form must include a bracketed flag list; a rule without flags is reported as ambiguous. Second, the leading-slash insertion is a documented scope assumption: it assumes the excerpt came from a document-root .htaccess, not from a nested folder with an Alias mapping. Third, the X-Robots-Tag mapping only fires when the value is a quoted string; conditional headers and environment variables stay manual.

Reading the Warnings Instead of Ignoring Them

The warning list is the most important output of the converter, because it tells you what the tool refused to do. A beginner should treat each warning as a checklist item, not as noise. The supported flag set is intentionally limited to L, R, R=301 and R=302. Unknown flags such as QSA, END, F, G, B or NC stop conversion for that rule, because their semantics cannot be erased safely — QSA appends a query string, F returns a 403, and NC controls case sensitivity in ways that change the matching surface area.

RewriteCond lines are never translated automatically. Apache conditions can inspect HTTPS state, host names, files, directories, query strings, headers and captured groups, and their evaluation order matters. When a RewriteRule follows a condition, the tool suppresses the rule rather than emit an unconditional redirect that could change traffic, create a loop or expose a route. The Apache no-substitution target, written as a single dash, is also withheld: it often combines with flags that alter access or processing without changing the URI, and a literal dash is not a safe Nginx replacement.

The general rule is simple: the more obscure the directive, the more you should read both the Apache and Nginx documentation side by side. Identical-looking regular expressions can still behave differently because the matched string, escaping, query handling and loop behaviour are not the same across servers.

A Safe Merge Checklist Before You Reload Nginx

The converter returns a fragment, not a complete configuration. It does not create an http, server or location block, choose a listen port, set server_name, configure TLS, locate a document root, preserve PHP routing, forward a proxy, or define logs. Placing the reviewed lines in the wrong context is the most common reason a beginner migration breaks. A line can be syntactically valid yet wrong for its context, which is why a manual checklist matters before any reload:

Back up the active configuration and keep an open recovery session.
Place rewrite rules inside a server or location block that matches the original Apache folder scope.
Validate the assembled file with nginx -t; a syntax pass is necessary but not sufficient.
Test representative requests on staging, including old paths, new paths, query strings, alternate hosts and HTTPS behaviour.
Start with temporary redirects in a controlled environment when practical, then switch to permanent only after the Location header is confirmed.
Treat the migration as engineering work whenever the source contains authentication, authorization, hotlink protection, proxy logic, CMS front-controller rules or complex conditions.

Permanent redirects deserve extra care because browsers and intermediaries can cache them. Confirm the response Location header rather than relying on the browser address bar alone. A failed reload or redirect loop can take a public site offline, and a cache that points old URLs at the wrong host is harder to undo than the original bug. If the source contains anything beyond the supported subset, treat the migration as engineering work rather than bulk text replacement.