.htaccess Generator

Generate the Apache .htaccess directives for the configurations sites need most often: forcing HTTPS, canonicalising www, 301 redirects, custom error pages and cache headers. Each rule is explained so you know what you are pasting.

Free · runs in your browser · updated

Configure Rules
Custom 404 Error Page Redirect URL path
Result file text

.htaccess Generator at a glance

What it does
Generate Apache .htaccess rules for redirects, forcing HTTPS, www canonicalisation, custom error pages and browser caching, with each directive explained.
Where it runs
Entirely in your browser — no data is uploaded
Works offline
Yes, once the page has loaded
Cost
Free, with no account and no usage limit

How to use the generator

  1. Choose the rules you need.
  2. Fill in your domain and paths.
  3. Back up your existing .htaccess before changing anything.
  4. Upload and test immediately - a syntax error here takes the whole site down with a 500.

An invalid directive in .htaccess produces a 500 Internal Server Error for every page. Always keep a copy of the working file where you can restore it quickly, and test in a browser as soon as you upload.

Force HTTPS

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

Behind a load balancer or CDN the connection to your server may already be plain HTTP even though the visitor used HTTPS. In that case test the forwarded header instead, or you will create a redirect loop:

RewriteCond %{HTTP:X-Forwarded-Proto} !https

Once HTTPS is working reliably, add HSTS so browsers stop trying HTTP at all:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Be deliberate about that one - it is difficult to undo, because browsers cache the instruction for the duration you specify.

Choose www or non-www, then be consistent

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

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

Which you pick matters far less than picking one. Serving the same content on both is duplicate content, splits your link signals, and doubles the URLs search engines have to reconcile. Combine this with an HTTPS redirect carefully so a request never takes two hops - chain them into one rule where you can.

Redirects

# Single page, permanent
Redirect 301 /old-page /new-page

# Whole directory
RedirectMatch 301 ^/old-section/(.*)$ /new-section/$1

# Pattern-based
RewriteRule ^products/([0-9]+)$ /shop/item/$1 [R=301,L]

Use 301 for permanent moves - it passes ranking signals and browsers cache it aggressively. Use 302 only when the change is genuinely temporary, since a 301 issued by mistake persists in users' browsers long after you fix the server.

Point redirects at the final destination rather than chaining them. Every hop adds latency and loses a little signal, and chains beyond a few links may not be followed at all.

Error pages and caching

ErrorDocument 404 /404.html
ErrorDocument 500 /500.html

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType application/javascript "access plus 1 year"
  ExpiresByType text/html "access plus 0 seconds"
</IfModule>

Long cache times on static assets are safe only if the filenames change when the content does - a build hash in the name. Without that, visitors keep a stale stylesheet for a year. HTML should not be cached long, since that is what points at the current asset filenames.

Make sure your custom error page actually returns a 404 status. A "not found" page served with a 200 is a soft 404, which search engines detect and treat as a quality problem.

A note on performance

Apache reads .htaccess on every request, and it checks every parent directory up to the document root. On a busy site this is measurable overhead.

If you control the server configuration, put these directives in the virtual host block instead and set AllowOverride None. That is faster and keeps the rules under version control. .htaccess exists for shared hosting where you cannot edit the main configuration - which is the situation most people are in, and where it remains genuinely useful.

None of this applies to nginx, which has no equivalent file. Nginx rules go in the server configuration and use different syntax entirely.

Frequently asked questions

Restore your backup immediately, then reintroduce the rules one block at a time to find the fault. The usual causes are a directive requiring a module that is not enabled, or a typo in a rewrite condition.

Either, consistently. Pick one, redirect the other to it with a 301, and set your canonical tags to match. Serving both creates duplicate content.

No. Nginx has no per-directory configuration file. The equivalent rules live in the server block and use different syntax.

It adds a small cost on every request because Apache re-reads it and checks parent directories. Where you can edit the main server configuration, put the rules there instead.

A rewrite rule on the old domain sending everything to the new one, preserving the path. Keep it in place for at least a year so links and search signals transfer fully.

Nothing you enter here leaves your browser

.htaccess Generator does its work in JavaScript running on your own device. The page loads once, and after that there is no upload step and no server involved — which matters here because site structure and configuration are worth keeping to yourself.

You can verify this rather than taking our word for it: load the page, disconnect from the internet, and the tool keeps working. Our privacy policy sets out what is and is not collected, and this guide explains why the distinction matters.