Redirect Code Generator

Features

• Eleven targets: Apache (.htaccess), Nginx, HTML meta refresh, JavaScript, PHP, classic ASP, ASP.NET, JSP, Java, Perl, Python
• Status 301, 302, 303, 307 or 308 — every target genuinely uses the value you pick
• ASP, ASP.NET, JSP and Java avoid Response.Redirect and sendRedirect, which can only send 302, and set the status and Location header explicitly
• Nginx distinguishes an exact match (location = /old) from a prefix match (write the source as /old/*)
• Apache output uses a mod_alias Redirect directive rather than a mod_rewrite rule
• Dollar signs and at signs in Perl output are escaped, so they are not interpolated as variables
• Several destination URLs produce several rules, up to twenty at a time
• Whitespace, quotes, backslashes and angle brackets in the address are rejected with an explanation instead of producing broken syntax
• The generated code is syntax-highlighted and can be copied in one go
• Everything runs locally in the browser; the destination is never uploaded

How to use

1. Paste the full destination address, one URL per line for several rules
2. Pick the target environment
3. For Apache or Nginx, also fill in the source path — where the old page lives on your site
4. Pick a status code: 301 for a domain change or a permanent move, 302 for a temporary campaign page
5. Copy the code; the comments at the top point out where it differs from what you asked for

FAQ

Should I use 301 or 302?

Use 301 for a domain change or a permanent move — search engines transfer the old address to the new one and replace it in the index. Use 302 for campaign pages, maintenance pages and A/B tests — the old address stays valid and the index is left alone. Getting it wrong is not symmetric: a 301 where you wanted a 302 gets cached by browsers and proxies for a long time, and visitors returning to the old URL may never see the original content again, whereas a 302 where you wanted a 301 only means the ranking signal was not transferred. When in doubt, start with 302.

Why do the JavaScript and meta refresh targets have no status code?

Because they redirect in the browser: the server still answers with an ordinary HTTP 200 page, and only then does the script or meta tag move the browser along. To a crawler or a proxy, nothing was redirected — the status code and cache behaviour still belong to the original page. So if the status code matters, use a server-side target (Apache, Nginx, PHP, ASP, JSP and friends). A meta refresh is only right for static hosting, where you have no server configuration to edit. The generated code carries a comment saying the same thing.

Why does the source path only apply to Apache and Nginx?

Because those two are the only targets where a configuration file describes which path goes where — the source path is the rule condition. The PHP, ASP and JSP outputs describe how a request should be answered; whether that code runs at all depends on which file or route you put it in, and the tool cannot know that. Inventing an if-statement would only produce a guess.

Why are the comments in the generated code in English?

They are going into a .php, .java or .cs file, next to code in that language. One comment in another language is the kind of small inconsistency that trips up whoever opens the file next — most likely you. Everything on this page — options, errors, explanations — follows your interface language.

What about question marks, non-Latin characters and spaces in the address?

Question marks, equals signs, ampersands and non-Latin characters are all fine and appear as-is in the generated code. Whitespace, quotes, backslashes and angle brackets are refused, with a prompt to percent-encode them first — those characters are escaped differently in each of the eleven languages, and picking one for you is a gamble whose failure shows up as a syntax error in your project rather than here.

Is the address uploaded anywhere?

No. The address and the status code are only concatenated in browser memory; the page makes no requests at all and works offline.