Free Tool
4.9/5

Free HTAccess Redirect Generator

Build clean Apache .htaccess redirect rules from a friendly form. 301, 302, 307, 308, regex RewriteRule, HTTPS-force, www toggle, trailing slash, all generated in real time.

Quick presets

Global rules

Site-wide canonicalization toggles. Applied before custom rules.

www handling

Pick one canonical hostname.

Trailing slash

Canonicalize URL endings sitewide.

Custom redirect rules

Each row generates one Redirect or RewriteRule directive.

1

Rule 1

Generated .htaccess

18 lines · 432 bytes

# Generated by Flyn HTAccess Redirect Generator
# https://www.flyn.to/htaccess-redirect-generator

<IfModule mod_alias.c>
  Redirect 301 /old-page /new-page
</IfModule>

<IfModule mod_rewrite.c>
  RewriteEngine On

  # Force HTTPS
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

  # Force non-www
  RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
</IfModule>

Paste this into the .htaccess file at your site's document root (usually /public_html/). Test the live redirects with the Flyn redirect checker after deploy.

Tired of redeploying for every redirect change?

Branded Flyn short links are editable from a dashboard, track every click, and survive domain migrations, no SSH or .htaccess edits required.

Shorten for free

How to Generate .htaccess Redirects in 3 Steps

Step 1: Add your redirect rules, HTAccess Redirect Generator screenshot
1

Add your redirect rules

Enter each source URL or pattern, its destination, and a status code (301, 302, 307, or 308). Toggle regex mode if your source needs pattern matching.

Step 2: Configure global rules, HTAccess Redirect Generator screenshot
2

Configure global rules

Flip switches for force-HTTPS, force-www (or non-www), and trailing-slash policy. The .htaccess block regenerates as you type, no submit button.

Step 3: Copy and deploy, HTAccess Redirect Generator screenshot
3

Copy and deploy

Copy the generated block and paste it into your site's .htaccess file at the document root. Verify the live redirects with our free redirect checker.

What Is an .htaccess Redirect?

.htaccess is a per-directory configuration file used by the Apache HTTP Server. Drop it in your site's document root and Apache reads it on every request, applying any directives it contains. The most common use is redirects, sending a request for one URL to a different URL with a status code that tells the browser (and search engines) what the move means.

Apache offers two main directives for redirects: Redirect from mod_alias (simple literal matching) and RewriteRule from mod_rewrite (regex-powered, with flags and conditions). This generator builds both, pick the right tool for the job and copy the output straight into your .htaccess file. Just remember: every rule lives or dies by Apache's AllowOverride setting, so if your rules silently do nothing, that's where to look first.

The 4 Core Redirect Directives

Apache gives you several ways to write a redirect. Each has a niche.

Redirect (mod_alias)

The simplest directive. Syntax: "Redirect 301 /old-path https://example.com/new-path". Matches the URL prefix literally, no regex. Use for one-to-one moves where the source is a specific path you control. Fastest option for static rules.

RewriteRule (mod_rewrite)

The flexible workhorse. Syntax: "RewriteRule ^old/(.*)$ /new/$1 [R=301,L]". Uses PCRE regex with backreferences, supports flags like [R] (redirect), [L] (last), [QSA] (preserve query), [NC] (case-insensitive). Requires "RewriteEngine On" at the top.

RewriteCond

Conditional logic that gates the next RewriteRule. Common pattern: "RewriteCond %{HTTPS} off" before the HTTPS-force rule, or "RewriteCond %{HTTP_HOST} !^www\." to detect missing www. Multiple conditions stack as AND; add [OR] flag for boolean OR logic.

RedirectMatch

The regex sibling of Redirect. Syntax: "RedirectMatch 301 ^/blog/(.*)$ https://blog.example.com/$1". Less powerful than RewriteRule (no flags, no conditions) but simpler when you only need pattern-based redirects without other logic.

301 vs 302 vs 307 vs 308, Quick Reference

Picking the wrong status code can quietly bleed SEO authority for months. Here's when to use each. For the deeper decision tree, including browser caching gotchas and the 307/308 strict variants, read the 301 vs 302 guide.

CodeMeaningWhen to use
301Moved PermanentlyPermanent moves. Transfers SEO authority. Cached aggressively.
302Found (Temporary)Short-term moves, A/B tests, maintenance. No SEO transfer.
307Temporary RedirectLike 302, but preserves the HTTP method (POST stays POST).
308Permanent RedirectLike 301, but preserves the HTTP method. Rarer in practice.

Common .htaccess Redirect Patterns

The redirect setups every site needs sooner or later.

Force HTTPS for all traffic

Use RewriteCond %{HTTPS} off followed by a RewriteRule that redirects to the same path on https://. This is the bedrock of any modern site, pair it with HSTS for full protection.

Force non-www (or www)

Pick one canonical hostname and stick with it. Mixed www/non-www splits link equity, breaks analytics, and confuses HSTS. Most modern sites prefer non-www for cleaner URLs.

Trailing slash policy

Decide whether /page or /page/ is canonical and 301-redirect the other to it. Without a policy, /page and /page/ are technically different URLs and can both rank, diluting SEO authority.

Domain migration

When moving from olddomain.com to newdomain.com, redirect every URL to its new equivalent with the path preserved. Use RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L].

Trailing slash policy

Pick one, adding a trailing slash on all URLs or removing all trailing slashes. Either is fine, but inconsistent slashing creates duplicate-content issues that hurt SEO.

Removing query strings

Strip campaign parameters or session IDs from the canonical URL with RewriteRule combined with RewriteCond %{QUERY_STRING}. Pair with rel="canonical" tags in HTML for belt-and-suspenders.

Common .htaccess Mistakes to Avoid

The five mistakes that break almost every first-time .htaccess deployment.

Forgetting "RewriteEngine On"

Without this line at the top, every RewriteRule and RewriteCond is silently ignored. Apache won't warn you, your rules just don't run. Always include it as the first directive inside the <IfModule mod_rewrite.c> block.

Wrong AllowOverride setting

If the main Apache config sets AllowOverride None for your directory, .htaccess files are entirely ignored. Check with your host, most shared providers allow All, but managed VPS setups often lock this down for performance reasons.

Missing [L] flag

Without the [L] (Last) flag, Apache keeps processing rules after a match, the rewritten URL is fed back through the rule list. This can cause infinite loops or unexpected behavior. Add [L] to every terminal redirect.

Forgetting to escape dots

In regex, "." matches any character, so "example.com" matches "examplexcom" too. Always escape with a backslash: "example\.com". A missing escape is the #1 cause of accidental over-matching.

Hardcoding domain in destination

Writing "RewriteRule ^old$ https://www.example.com/new" works for one site, but moving to a staging/dev environment breaks. Use %{HTTP_HOST} or relative paths where possible to keep rules portable across environments.

Edit-Anywhere Redirects with Flyn

Use .htaccess for site-internal canonicalization. Use Flyn short links for every redirect you might want to change later, no SSH or redeploy required.

Edit from a dashboard

Change a destination in two clicks. No SSH, no FTP, no waiting for the next deploy window.

Sub-50ms redirects

Global edge delivery makes Flyn redirects faster than most origin .htaccess setups.

Click analytics built-in

Every redirect logs device, country, referrer, and time. .htaccess just rewrites, Flyn measures.

Survives domain migrations

When you move domains, change the destination once, every shared short link keeps working.

Frequently Asked Questions

What is an .htaccess file?
.htaccess (hypertext access) is a per-directory configuration file used by Apache HTTP Server. When Apache loads a request, it walks from the document root down to the requested file, applying any .htaccess directives it finds along the way. Common uses include URL rewriting, redirects, password protection, custom error pages, and MIME type mapping. The file is hidden by default (the leading dot makes it dot-files on Unix) and is read on every request unless AllowOverride is restricted, so misconfigurations can have an immediate impact on every page on the site.
Where do I put my .htaccess file?
Place .htaccess in the root of the directory you want the rules to affect, usually the document root (public_html, htdocs, www, or wherever your site is served from). Rules apply to that directory and every subdirectory, unless overridden by another .htaccess deeper in the tree. For most shared hosts (cPanel, Hostinger, SiteGround, Bluehost), this means uploading it to /public_html/. The file must be readable by the web server user and AllowOverride must be set to All (or at least FileInfo) in the Apache main config, otherwise the directives will be silently ignored.
What is the difference between Redirect and RewriteRule?
Redirect (from mod_alias) is the simpler directive. It does literal-prefix matching and issues an HTTP redirect to the browser. RewriteRule (from mod_rewrite) is more powerful: it uses regular expressions, supports backreferences, conditions (RewriteCond), and flags like [R=301,L] to control behavior. Use Redirect for simple one-to-one mappings ("/old-page" → "/new-page"). Use RewriteRule when you need patterns ("/blog/(.*)" → "/news/$1"), conditional logic (only redirect HTTP, only redirect www), or internal rewrites that don't change the URL bar.
When should I use 301 vs 302 redirects?
Use 301 (Permanent) when the move is permanent, old URL → new URL forever. Search engines transfer link equity, browsers cache aggressively, and most users never hit the old URL again. Use 302 (Found / Temporary) when the redirect might change, A/B tests, geo-targeting, maintenance pages, or short-lived campaigns. Search engines keep indexing the old URL and don't transfer ranking power. Getting this wrong matters: a 302 where you meant 301 will silently bleed SEO authority for months. Test live redirects with our free redirect checker after deploying.
What regex syntax does RewriteRule use?
RewriteRule uses Perl-Compatible Regular Expressions (PCRE). Common patterns: ^ anchors the start, $ anchors the end. matches any single character, .* matches zero or more of anything, (.*) captures into a backreference accessible as $1, $2, etc. Character classes like [a-z0-9-]+ match URL-safe segments. Escape literal dots with \. so they don't match arbitrary characters, a missing escape is the #1 source of accidental over-matching. Use a tool like regex101.com to test patterns before deploying them.
Why aren't my .htaccess redirects working?
The five most common causes: (1) AllowOverride is set to None in the main Apache config, your .htaccess is ignored. (2) mod_rewrite isn't loaded, run a2enmod rewrite on Debian/Ubuntu. (3) You forgot "RewriteEngine On", without it, all RewriteRule directives are silently ignored. (4) Browser caching, old 301s are cached aggressively. Test in an incognito window, or clear cache before re-testing. (5) Rule order matters, Apache stops at the first matching rule unless you add the [L] flag to chain them correctly. Always test with curl -I to see the raw response. If your host will not enable .htaccess at all, a client-side meta refresh redirect is the fallback that needs no server config.
How is .htaccess different from nginx config?
nginx has no .htaccess equivalent, there's no per-directory config loaded on every request. All redirects and rewrites go in nginx.conf or a site-specific file in /etc/nginx/sites-available/, then you reload nginx (nginx -s reload). This is faster (no per-request file lookup) but requires server access, you can't change rules without SSH. nginx syntax is different too: location blocks with return 301 https://$host$request_uri; instead of RewriteRule. If you migrate from Apache to nginx, you'll need to translate every rule, there's no automatic conversion.
Do .htaccess redirects hurt performance?
Yes, marginally. On every request Apache must check for .htaccess in every directory from the document root down to the target file, which adds disk I/O. For high-traffic sites, moving rules into the main httpd.conf (where they're loaded once at startup) gives a measurable speed boost. The redirect itself is fast, a few microseconds of CPU, but the lookup overhead scales with directory depth and traffic. Most small-to-mid sites won't notice, but a site doing 10k req/sec on shared hosting will. CDN-level redirects (Cloudflare Page Rules, Vercel, Netlify) skip the origin entirely and are essentially free.
How do I test my htaccess redirects?
After deploying, verify with our free redirect checker, it traces the full chain and shows status codes, hop count, and timing. For local testing, use curl -I https://yoursite.com/old-url to see the raw HTTP response, look for HTTP/1.1 301 Moved Permanently and the Location header. Browser dev tools (Network tab, with "Preserve log" checked) also show the redirect chain. Always test in incognito to avoid cached redirects masking a broken rule, and test on both HTTP and HTTPS schemes to confirm both paths work.
Can I redirect to an external URL with htaccess?
Yes, both Redirect and RewriteRule support absolute URLs as the destination. For example: "Redirect 301 /old https://example.com/new" or "RewriteRule ^old$ https://example.com/new [R=301,L]". Apache issues a real HTTP redirect, so the user's browser ends up at the external domain with a fresh URL bar. The only gotcha: the destination domain's SSL certificate and DNS must work, Apache won't verify either, it just emits the Location header. For complex external redirects (campaign tracking, click analytics, A/B routing), use a branded Flyn short link instead, you get edit-without-deploy, click data, and survives any domain migration.
What if multiple rules match the same URL?
Apache evaluates directives in file order, and behavior depends on the directive. Redirect (mod_alias) processes all matching directives but uses the first match per request. RewriteRule (mod_rewrite) processes rules top to bottom, applies the first match, and either stops (if [L] flag is set) or continues with the rewritten URL through subsequent rules. This means rule order is critical: put more specific rules above general ones, and always use [L] (Last) on terminal rules to prevent further processing. Conflicting rules can cause redirect loops, if browser shows ERR_TOO_MANY_REDIRECTS, that's usually two rules redirecting back and forth.
Why use Flyn short links instead of htaccess redirects?
File-based redirects need server access and a redeploy every time you change them. Flyn branded short links solve the same problem with three advantages: (1) Edit anytime from the dashboard, no SSH, no deploys, no waiting for ops. (2) Full click analytics, device, country, referrer, and time per click, none of which .htaccess can give you. (3) Survives domain migrations, change your destination URL once, every previously-shared link follows. Pair the two: use .htaccess for site-internal canonicalization (HTTPS, www, trailing slash), and Flyn short links for every shared external link.

Want redirects without redeploys?

.htaccess is great for site-internal canonicalization. Flyn branded short links are better for everything you might want to change later, with click counts, QR codes, and edit-anytime URLs on the free plan; full analytics and custom domains on Pro.