Htaccess Redirect Generator Free Tool

About Htaccess Redirect Generator

What This Tool Actually Does

The Htaccess Redirect Generator on this page is a small browser tool with a single job. It prints a three-line Apache rewrite block that sends all traffic from one hostname variant of your domain to the other. You choose whether you want www in the address or not, type your domain, and the tool writes the rules for you.

Everything happens in your browser. The JavaScript on this page reads your radio choice and your typed domain, then assembles the text. No data travels to any server. The page's own server-side route for this tool is disabled and answers with a malformed request error if something calls it directly. The generation itself makes no network request at all.

The tool exists because the www versus non-www choice is one of the oldest decisions in website publishing. Search engines treat www.example.com and example.com as separate hosts until you tell them otherwise. A permanent redirect from one to the other consolidates your signals. Apache has supported this kind of rule for decades through its mod_rewrite module, and the same syntax works on LiteSpeed and OpenLiteSpeed servers.

You get exactly three lines. For the default www to non-www direction, with example.com typed in, the output is this.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.example.com [NC]
RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]

Switch the radio button to non-www to www and the output changes to this.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example.com [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]

The feature set ends there. There are no fields for source paths, destination URLs, status codes, or folders. There is no copy button and no download. The output box selects all its text when you click it, so you can press Ctrl+C or Command+C and paste the block into your .htaccess file.

How to Use This Tool

The page lays out four numbered steps, and the workflow is short enough to describe in six.

1. Open the tool page. Find the input area above this article with the two radio buttons and the domain text box.
2. Choose your redirect direction. Select "Redirect from www to non-www" if you want the bare domain to be canonical, or select "Redirect from non-www to www" for the opposite.
3. Type your domain. Enter your domain without the www prefix, for example yourdomain.com. The box accepts up to 127 characters.
4. Generate the code. Press the "Get .htaccess Code" button or hit Enter. Both run the same function.
5. Copy the block. Click inside the output text box. The tool selects all three lines, then press Ctrl+C on Windows or Command+C on a Mac.
6. Paste into your .htaccess file. Open the .htaccess file in your site's root directory and paste the block above any existing rules, especially above the WordPress section if you run WordPress.

The tool clears the output box if your input fails validation. A browser alert appears with the message "Invalid domain name. Please check and try again!" and you start over.

What the Three Lines Actually Do

Each line in the generated block has a specific role in Apache's rewrite engine. Understanding them helps you adapt the code when your situation differs from the simple case.

The first line, RewriteEngine On, turns on the rewriting engine for this directory context. Apache does not process rewrite rules until this directive appears. You only need it once per .htaccess file, even if you paste multiple rule sets. If your file already has this line from another rule, you can delete the duplicate.

The second line is the condition. RewriteCond %{HTTP_HOST} ^www.example.com [NC] tells Apache to look at the Host header that the browser sent in its request. The ^ anchor means the hostname must start with www.example.com. The [NC] flag makes the comparison case-insensitive, so WWW.EXAMPLE.COM also matches.

The third line is the rule itself. The pattern ^(.*)$ captures everything in the request path after the domain. The $1 placeholder puts that captured path back into the destination URL. The [L] flag stops processing further rules in this pass. The [R=301] flag tells Apache to issue a permanent redirect response and send the browser to the new location.

The query string needs no special handling here. When Apache performs a redirect without a ? in the target and without the QSD flag, it appends the original query string automatically. A request to http://www.example.com/page?id=42 becomes http://example.com/page?id=42 with the query intact.

The three lines do not handle HTTPS. The target URL is hard-coded to http://, never https://. This single fact shapes most of the tool's limitations.

The http:// Target Problem on HTTPS Sites

The generated rules send visitors to the http:// version of your destination. If your site runs on HTTPS, which most sites do in the 2020s, this creates a problem.

A visitor types https://www.example.com/page into their browser. Your server receives that request over HTTPS. The rewrite condition matches the hostname, and Apache responds with a permanent redirect to http://example.com/page. The browser follows that redirect over plain HTTP. If your server then has a separate rule that forces HTTPS, the browser gets redirected a second time to https://example.com/page. That is a two-hop chain, and the first hop briefly downgrades the connection to unencrypted HTTP.

The situation is worse if you have no HTTPS-forcing rule at all. The visitor lands on the insecure version of your page, and any sensitive data they submit travels without encryption. Search engines and browsers increasingly flag such sites. Google Chrome has shown "Not secure" warnings for HTTP pages since 2018.

The correction takes one edit. After generating the code with this tool, change http:// to https:// in the target URL on the third line. The three lines then read as follows for the www to non-www direction.

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

Do the same for the non-www to www direction. This small edit removes the downgrade and the extra hop. The modern approach many hosts recommend combines the HTTPS check with the www check in a single rule.

Correcting the Old Description of This Tool

The previous version of this page described capabilities that the real tool does not have. That old copy was roughly 2,800 words long and made several claims that a direct test on September 4, 2026 disproved. The tool performs no live test of any kind.

The old page said you could enter a source path and a destination URL. The form has no such fields. It has one text box for a domain name and two radio buttons for direction. There is no way to specify /old-page as a source or https://othersite.com/new-page as a destination.

The old page said you could pick between a permanent and a temporary redirect. There is no status code selector. Every generated rule carries the permanent redirect flag. A temporary redirect is never produced by this tool.

The old page claimed the tool generates Redirect and RedirectMatch directives, folder redirects, page-to-page redirects, domain-to-domain redirects, trailing-slash rules, and force-HTTPS rules. The tool generates exactly one kind of output, the three-line mod_rewrite block for the www and non-www hostname pair. Nothing else is possible through the interface.

The old page said the output uses https:// targets and handles HTTPS. The generated code hard-codes http://. The tool has no knowledge of your certificate setup and no field for a protocol preference.

The old page said the tool validates or tests the redirect. The validation is loose. It cannot fetch your site, follow a redirect, or confirm that your server reads .htaccess files at all.

These corrections matter because bad copy leads to bad expectations. A site owner who expects folder redirects will paste the generated block, see that it does nothing for their folder, and lose time debugging. A site owner who expects HTTPS output will deploy the code and accidentally downgrade visitors to HTTP. The tool's scope is narrow, and knowing that scope prevents those failures.

Limitations

The Htaccess Redirect Generator has real limits, and most of them come from the code itself. Knowing them before you paste anything saves you from a confusing afternoon.

The domain validation is loose. The tool checks that your input contains letters, digits, hyphens, or underscores, then a dot, then more of the same. After the first dot, it also permits percent signs, ampersands, question marks, slashes, and equals signs. This pattern lets several wrong inputs through. Typing www.example.com passes validation, and the output then contains a condition for ^www.www.example.com or a rule that never matches. Entering example.com/path passes too, and the generated code embeds the slash into the hostname condition, which never matches a real request. A bare example or localhost fails validation, and a Unicode internationalized domain name fails as well.

The regex in the condition is sloppy. The dots in ^www.example.com are not escaped, and in regular expressions a dot matches any character. So the condition also matches wwwXexampleXcom or any other string with arbitrary characters in those positions. In practice this is harmless because real hostnames contain dots, but it is not precise. The condition also has no closing $ anchor, so www.example.com.evil.com would match the pattern. Apache evaluates the rule top to bottom and the first match wins, so a carefully crafted hostile Host header could trigger the redirect. The pattern is not what a careful administrator would write by hand.

The tool only handles the two hostname variants. It cannot generate a redirect for a specific page, a folder, a complete domain change, or a trailing-slash policy. It always emits a permanent redirect. It never emits an HTTPS URL and never combines the HTTPS check with the hostname check.

The tool makes no request to this site when you generate code. The rate limit that applies to other pages on this site, roughly fifteen requests within one second from a single visitor address triggering a block for the rest of the day, does not affect the generation itself. Only the initial page load counts against that shared throttle.

The output box has no copy button. You select the text manually. The tool selects all of it when you click the box, which is a small convenience, but there is no one-click clipboard action.

Where the Code Goes in .htaccess

The placement of your generated block inside .htaccess affects whether it works at all. Apache reads the file from top to bottom and applies the first matching rule. The order matters.

Your .htaccess file lives in the document root of your site, the same directory that contains your main index.php or index.html. Apache only reads it when the server configuration permits, through the AllowOverride directive. Many shared hosts enable this by default. Nginx, the other major web server, ignores .htaccess entirely, so if your site runs on Nginx this tool's output will do nothing until you translate the rules into Nginx's server block syntax.

For a WordPress site, the .htaccess file usually contains a block that WordPress itself manages. It starts with # BEGIN WordPress and ends with # END WordPress. Your generated redirect block must go above that WordPress section. Paste it before the # BEGIN WordPress comment line. If you paste it inside the WordPress-managed region, WordPress may overwrite it during a permalink update or a plugin operation.

The rule set does not need to appear at the very top of the file. It needs to appear before any rule that would match the same request and stop processing with the [L] flag. WordPress's own rewrite block sits at the bottom and catches everything that reaches it, so placing your redirect above it is the safe choice.

A common mistake is pasting the block into a subdirectory .htaccess file. The rules then apply only to requests under that subdirectory, and the hostname condition may never match as you expect. Put the block in the root .htaccess for a site-wide redirect.

The RewriteEngine On line enables the rewrite engine. If your file already contains this directive, the duplicate is harmless but untidy. Apache processes the second RewriteEngine On as a no-op. You can leave it or delete it.

Testing Your Redirect After Installation

You have pasted the block and saved the file. Verify that the redirect actually fires. This tool does not test anything, but this site offers a companion tool that does.

The www Redirect Checker on this site follows your redirect and reports the chain. Use it after you install the generated code. Enter the URL with the www prefix if you redirected to non-www, or the bare domain if you redirected the other way. The checker shows you each hop and the final destination.

A permanent redirect response gets cached by browsers. Once your browser sees that status for a given URL, it remembers the destination and may not even contact your server on the next visit. This caching behavior means your normal browser is a poor test instrument. Open a private or incognito window for each test, or use the redirect checker tool, which does not cache results the way a browser does.

The live test run for this rewrite on September 4, 2026 confirmed the tool's output matches the three lines shown above. Typing example.com with the default option produced the www to non-www block exactly. Switching the radio button produced the non-www to www block. Typing example without a dot produced the invalid domain alert. The tool behaves as described in this article.

When you test, check three things. First, the destination hostname is the one you wanted. Second, the protocol is HTTPS if your site uses HTTPS, which means you edited the http:// to https:// in the third line. Third, the path and query string survive the redirect. A request to https://www.example.com/products?id=7 should land on https://example.com/products?id=7 with both the path and the query intact.

The Domain Validation Problem in Detail

The loose validation deserves a closer look because it produces silently broken output. The tool's pattern check accepts strings that no real domain should contain, and the generated code then embeds those strings into the rewrite condition.

The pattern requires a sequence of letters, digits, hyphens, or underscores, then a dot, then more of the same. After that first dot, the pattern also allows percent signs, ampersands, question marks, slashes, and equals signs. This permissive pattern accepts common domain forms.

Typing www.example.com into the box passes validation. The tool then substitutes that whole string into the condition line. For the www to non-www direction, you get RewriteCond %{HTTP_HOST} ^www.www.example.com [NC]. No real request has a Host header starting with www.www, so the condition never matches and no redirect ever happens. For the non-www to www direction, you get RewriteRule ^(.*)$ http://www.www.example.com/$1 [L,R=301]. Here the condition ^www.example.com does match the Host header www.example.com, so the rule fires and sends every visitor to the wrong host www.www.example.com, which does not exist.

Typing example.com/path passes validation too. The generated condition becomes ^example.com/path, which never matches a Host header because Host headers contain only the hostname, not a path. The redirect silently does nothing.

The validation failure modes are equally instructive. A bare example fails because there is no dot. localhost fails for the same reason. An internationalized domain name in Unicode, such as münchen.de, fails because the pattern only allows ASCII letters, digits, hyphens, and underscores. If you operate an IDN, you need the punycode form that starts with xn--. The tool accepts that ASCII form because it fits the pattern.

The practical advice is to type your domain exactly as it appears in your browser's address bar minus the www, with no protocol prefix and no trailing slash. If the tool accepts something that looks wrong, inspect the output before pasting it. The output box shows you the exact lines, and a quick read tells you whether the hostname in the condition matches reality.

What This Tool Cannot Generate

The scope of this tool is narrow, and listing what it cannot do prevents the most common misuse. The old page on this site claimed several capabilities that the tool simply lacks.

There is no page-to-page redirect. You cannot turn /old-article into /new-article with this tool. That requires a rule with specific source and destination paths, and this tool only accepts a domain name.

There is no folder redirect. You cannot send example.com/old-folder/ to example.com/new-location/. The tool has no concept of folders.

There is no domain-to-domain redirect. You cannot redirect old-domain.com to new-domain.com. The tool only varies the www prefix on a single domain.

There is no temporary redirect. Every output line contains the permanent redirect flag. If you need a temporary redirect for testing or for a short-lived campaign, you must edit the code by hand, changing the status code in the flag.

There is no force-HTTPS rule. The tool never inspects the protocol and never emits a rule that checks %{HTTPS}. The generated code sends visitors to http://, which is the opposite of a force-HTTPS rule.

There is no combined rule that handles both HTTPS and the www decision in one pass. The modern recommended pattern for Apache looks something like this, and this tool does not produce it.

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

There is no support for Redirect or RedirectMatch directives from Apache's mod_alias module. The tool only emits mod_rewrite syntax. The tool commits to one redirect behavior for both modules.

There is no test or validation of the live redirect. The tool checks your input against a pattern and refuses obviously malformed strings, but it does not fetch your site, follow the redirect chain, or confirm that your server reads .htaccess.

There is no handling of subdomains beyond the www variant. Typing sub.example.com passes validation, but the tool treats it as a domain and generates a rule that compares the Host header against ^sub.example.com. The output may work for that subdomain, but the tool's interface and copy assume a single registered domain.

Related Tools

When you need to rewrite URLs for reasons other than the www choice, the Htaccess URL Rewrite tool on this site handles more general rewrite patterns, including paths and query strings.

After you install your redirect, verify it with the www Redirect Checker, which follows the redirect chain and shows you each hop without the caching problems of a normal browser.

If you are building a new site and need to control which pages search engines may crawl, the Robots.txt Generator creates the companion file that works alongside your redirect rules.

The Relationship Between .htaccess and Your Server

A redirect rule only works when the server software reads the file that contains it. This tool generates Apache syntax, so the surrounding server context determines whether the output has any effect.

Apache has supported .htaccess files since version 1.3 in the late 1990s. The server reads these per-directory configuration files on every request, which is why Apache is slightly slower than Nginx on high-traffic static sites. The AllowOverride directive in the main server configuration controls whether .htaccess files are honored at all. On many shared hosts, AllowOverride All is the default, and the hosting control panel documentation tells you where to put your files.

LiteSpeed and OpenLiteSpeed, popular commercial and open-source Apache-compatible servers, read .htaccess files and understand mod_rewrite syntax. If your host uses LiteSpeed, the output from this tool works as-is. The same three lines behave identically.

Nginx ignores .htaccess completely. Nginx reads its configuration from nginx.conf and from included files in the sites-available or conf.d directories. There is no per-directory configuration file that Nginx reads dynamically. If your site runs on Nginx, you must translate the rewrite logic into an Nginx server block using the rewrite directive or the return directive with the permanent status. The tool's output gives you the logic, and the translation requires a small amount of Nginx-specific syntax.

You run a redirect test to check the tool's behavior. Create a small PHP file in your site root with <?php echo 'ok'; ?> and request it. If it loads, your server handles dynamic files. Then check your hosting documentation for whether you use Apache, LiteSpeed, or Nginx. The hosting control panel usually states this clearly.

How Search Engines and Browsers Treat Permanent Redirects

The tool emits the permanent redirect flag, and that status code carries specific consequences. A permanent redirect tells the client that the requested resource has a new permanent location. Search engines and browsers handle this status in ways that affect your testing and your site's long-term behavior.

Google's documentation has recommended permanent redirects for consolidating duplicate hosts since the early 2000s. The company's webmaster guidelines have long advised site owners to pick a preferred domain, either with or without www, and redirect the other variant to it. Google Search Console lets you set a preferred domain, though the setting has become less prominent over the years. The redirect itself remains the primary mechanism.

Browsers cache permanent redirect responses aggressively. Chrome, Firefox, and Safari all remember the destination of a permanent redirect and may skip the request to your server entirely on subsequent visits. This caching is why your normal browser is a poor tool for testing redirect changes. The private window test is the standard workaround. Close the private window after each test, because the cache persists within that window's session.

A permanent redirect also passes most of the link equity from the old URL to the new one. This is why the www decision matters for search engine optimization. If half your inbound links point to www.example.com and half point to example.com, search engines see two separate sites with divided authority. A permanent redirect from one to the other consolidates that authority into a single host.

The tool's output does not include a Cache-Control header or any other HTTP header beyond what Apache adds. The browser's caching behavior for permanent redirect responses is governed by the HTTP specification, RFC 7231, which states that such a response is cacheable unless otherwise indicated. In practice, browsers cache permanent redirects even without explicit cache headers.

The Modern Combined Rule

The generated three-line block solves the www problem for a basic Apache setup. Many hosts and security guides recommend a combined rule that handles both the HTTPS check and the www check in one condition. This tool does not generate that rule, but understanding it helps you decide whether to edit the output.

The combined rule for a canonical non-www HTTPS site looks like this.

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

The first condition matches when the request arrives over plain HTTP. The [OR] flag joins the two conditions, so the rule fires when either the protocol is HTTP or the hostname starts with www. The single redirect then sends the visitor to the HTTPS non-www version of the URL. There is no two-hop chain and no downgrade.

The tradeoff is readability. The combined rule packs two decisions into one condition block, which makes it harder to read at a glance. The tool's three-line output separates the concerns, which makes it easier to understand but requires the manual https:// edit and leaves the HTTPS enforcement to a separate rule.

If your site already has a force-HTTPS rule elsewhere in your .htaccess, the tool's output works fine after you change the target to https://. The visitor hits the www redirect first, lands on the HTTPS version because your other rule enforces it, and the chain completes in two hops. The extra hop is a minor performance cost, not a correctness problem.

If your site has no force-HTTPS rule, you have two choices. Edit the tool's output to use https:// and add a separate rule that redirects all HTTP traffic to HTTPS. Or replace the tool's output with the combined rule above. Either approach gives your visitors a single redirect from HTTP to HTTPS and from www to non-www.

Frequently Asked Questions

Does this tool send my domain to a server for processing?

No. The entire generation happens in your browser with JavaScript. Nothing is transmitted to this site's server when you click the button. The page load itself counts against the site-wide rate limit, but the code generation makes no request at all.

Why does the output use http:// instead of https://?

The tool's code hard-codes the http:// protocol into the target URL. It has no field for protocol selection and no way to know whether your site uses HTTPS. You should edit the third line by hand, changing http:// to https://, before you paste the block into your .htaccess file.

I typed www.example.com and the tool accepted it. Is that a problem?

Yes. The validation is loose and accepts input that begins with www. The generated code then contains a condition for www.www.example.com or a rule that never matches. Type your domain without the www prefix, exactly as the hint below the input box says.

Where exactly should I paste the generated code?

Paste it into the .htaccess file in your site's root directory, above the # BEGIN WordPress block if you run WordPress. The rules are evaluated top to bottom, and WordPress's own rewrite rules at the bottom would catch requests that your redirect should handle first.

How do I test whether the redirect works?

Open a private or incognito browser window and visit the URL you want to redirect. A permanent redirect is cached by browsers, so a normal window may show you a stale result. Alternatively, use the www Redirect Checker on this site, which follows the redirect chain without browser caching.

Can this tool generate a redirect from one domain to another?

No. The tool only handles the www and non-www variants of a single domain. It cannot redirect old-domain.com to new-domain.com, move a folder, or rewrite a specific page path. For those tasks you need a hand-written rule or a different tool that accepts source and destination paths.