BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
Nginx Redirect Generator
An Nginx redirect generator turns a plain list of old and new URLs into the exact Nginx directives a server needs to send visitors and search engines to the right page. Nginx does not use per-directory .htaccess files, so every redirect lives in the server config and must be written as a location, return, rewrite, or server block. A misplaced if, an unescaped dot in a regex, or a 302 used where a 301 belongs can leak link equity, trigger redirect loops, or break a launch the moment nginx reloads.
This tool builds paste-ready return and rewrite rules for single redirects, bulk old,new maps, HTTPS and www canonicalization, and complete HTTP-to-HTTPS server blocks. It is free and runs entirely in the browser, so even an unpublished redirect map for a confidential migration never leaves the page.
/old-page.html
example.com
🔒 Private: everything runs in your browser. Nothing you paste is uploaded.
How to use the Nginx redirect generator
Pick a tab, fill in the fields, and copy the generated config straight into your server block or http context. Every directive is built live in the browser as you type.
Generate a single redirect with the right return code
On the Single tab, enter the old location and the destination URL or path, then pick a status code. Use 301 for permanent moves so PageRank and link equity pass to the new URL, 302 or 307 for genuinely temporary changes, and 410 when a page is gone for good. The exact match style emits a tight location = /old block with a single return, while prefix mode writes a regex location that forwards an entire old folder to a new one and preserves the remaining path with a capture group.
Convert a whole migration map in the Bulk tab
During a migration you usually have a spreadsheet of old and new URLs. Paste it into the Bulk tab as one old,new pair per line and the generator outputs every rule in one pass, skipping blank lines and flagging any row missing a comma or a value. Choose the location style for a readable handful of redirects, or the map directive when the list runs to hundreds or thousands of rows, because a single hashed map lookup scales far better than thousands of individual location blocks.
Add canonical rules and a full HTTPS server block
The Canonical tab generates the host and scheme recipes every site needs: force HTTPS, redirect www to non-www or the reverse, and strip trailing slashes, all using $host and $request_uri so the path survives the redirect. The Server block tab goes further and writes the recommended pattern: a port 80 listener that sends all HTTP traffic to HTTPS, a second block that folds the non-canonical host into the canonical one, and an optional HSTS header. Paste it, swap in your certificate paths, and reload.
Nginx redirect generator frequently asked questions
Q1Should I use return or rewrite for an Nginx redirect?
Prefer return for almost every redirect. A return directive is faster, clearer, and sends an explicit status code in a single line, with no regex engine involved. Reserve rewrite for cases where you must transform the path with a regex capture, like forwarding an entire old folder to a new one while preserving the rest of the URL. This generator uses return for exact and bulk redirects and rewrite only when a pattern genuinely needs it.
Q2Where do I put these directives in my Nginx config?
Single redirects, canonical rules, and server blocks go in the server context, usually in a site file under sites-available or conf.d. A map directive is the exception: it must sit in the http context, outside any server block, with the lookup referenced inside the server. After editing, run nginx -t to test the syntax, then reload with nginx -s reload so the change takes effect without dropping connections.
Q3Why does the tool sometimes use a server block instead of a location?
Host and scheme canonicalization, like HTTP to HTTPS or www to non-www, is cleanest as a dedicated redirect server block rather than an if-condition inside the main server. A separate listener with its own server_name matches the request before any location logic runs, avoids the well-known pitfalls of if in nginx, and keeps the canonical site config uncluttered. The Server block tab generates exactly that recommended structure.
Q4Will these redirects cause an infinite loop?
A loop happens when a redirect points a URL back at itself, often from mixing a www rule with its reverse or redirecting to a host that redirects back. The generator warns when a single source and target look identical and flags conflicting canonical choices. Still test after reloading with curl -I against each URL, and confirm each one returns the expected status code once, because browsers cache 301s aggressively and can mask a fix.
Q5Is my redirect data sent to a server?
No. Every directive is generated locally with client-side JavaScript, and nothing you type or paste, including a full migration map, is uploaded, logged, or stored. The tool keeps working after the page has loaded even with no connection, which makes it safe to use for unpublished sites, internal redirect plans, and confidential migrations that should never touch a third-party server.
