Developer Tools New Tool

Free Online Htaccess Generator for Apache Rewrites and Headers

Choose the rules you need and read back a complete .htaccess with the parts in an order that works. Rewrites come before the front controller, compression and caching are wrapped in the module guards that stop a missing module taking the site down, and the panel shows the order.

Free Forever Nothing Uploaded Rules in a working order Runs in your browser

Free Online Htaccess Generator for Apache Rewrites and Headers

Advertisement Slot (Top Banner) Google AdSense Unit • Responsive Banner

Htaccess Generator Everything happens in this tab. Nothing you paste is sent anywhere.

What this file will do, in order

Keep a copy of your working file before you replace it. A single bad line here returns a 500 for every page on the site, including the one you would use to fix it.

.htaccess

Addresses Force HTTPS Host Trailing slash RewriteBase

Redirects Status One per line: the old path, a space, then the new path or URL.

Front controller Send everything not on disk to one file File

Error pages Custom error pages 404 403 500

Access No directory listing Block dotfiles Block these files

IP rules One address or range per line, such as 203.0.113.4 or 203.0.113.0/24.

Performance and headers Compression Browser caching Security headers HSTS

Buy Us A Coffee

Enjoying WizTools123? Help keep our server infrastructure 100% free and open for everyone.

Buy Us A Coffee

Sponsored Content (Below Tool) Google AdSense Placement

Why the Order Cannot Be Rearranged

The front controller has to be last, and redirects have to be first.

Rewrite rules are read from the top, and a rule ending in [L] stops the pass. A front controller rule catches every request that is not a real file or directory and hands it to index.php, so anything written after it never runs for those requests. That is why a redirect added to the bottom of a Laravel or WordPress .htaccess appears to do nothing at all: the front controller got there first.

Protocol and host rules go at the very top for a different reason. If you redirect /old to /new before forcing HTTPS, a visitor arriving on http://example.com/old gets two redirects instead of one, which costs a round trip and loses a little link equity at each hop. Fixing the protocol and the host first means every later rule is working on the final address.

Everything that is not a rewrite, the error pages, the file blocks, the compression and caching blocks and the headers, is order independent, so those are written after the rewrite section in a fixed grouping that stays readable. The panel on the left shows the order as it will be written, which is worth a glance before you paste.

How to Build an Htaccess File

A few steps, and nothing is uploaded.

Tick what you need Start with HTTPS and the host, since those two decide what every other rule sees. Leave anything you are unsure about switched off.

Add your redirects One per line: the old path, a space, then the new path or a full URL. Choose 301 for a permanent move and 302 only if the old address is coming back.

Check the order in the panel It lists the sections as they will be written. If you use a front controller, notice that it comes after the redirects, which is the only order that works.

Back up, then paste Save a copy of your current .htaccess first. Upload the new one, then load a page. If you get a 500, restore the copy and add the rules back one section at a time.

What to Know About .htaccess

Including the mistake that returns a 500 for every page.

One bad line returns a 500 for the whole site. Apache reads .htaccess on every request, and a syntax error or a directive the server does not allow does not get skipped: it fails the request. Because the failure applies to every URL, the admin page you would use to fix it is down too. Always keep a copy of the working file where you can restore it without the site, and test by loading a page immediately after uploading.

This is Apache only, and nginx cannot use any of it. nginx has no per-directory configuration file at all; the equivalent rules live in a server block in the main configuration and have completely different syntax, and a reload is required. Caddy, IIS and LiteSpeed differ again, although LiteSpeed does read .htaccess. Pasting this file onto an nginx host does nothing: it is not read and not an error.

The module guards are there for a reason, and it is not tidiness. Compression, caching and header directives are wrapped in <IfModule> so that a host without mod_deflate, mod_expires or mod_headers serves your pages instead of a 500. The cost is that a typo inside a guard fails silently, so if caching seems to do nothing, check that the module is actually enabled.

This writes a file; it cannot test it against your server. Nothing here knows which Apache version you are on, whether AllowOverride permits these directives, or whether your host has already put rules in the parent configuration. Shared hosting frequently forbids Options, in which case that one line is enough to bring the site down until you remove it.

Key Features & Capabilities

What this tool does, and what it deliberately does not.

A working order Protocol, host, redirects, then the front controller last.

HTTPS and host rules One hop to the canonical address, not two or three.

Blocks and headers Dotfiles, named files, listings, and the four useful headers.

Compression and caching Sensible max-age per file type, wrapped in module guards.

Shows the plan A panel lists what the file will do before you paste it.

Nothing is uploaded Paths and IP addresses stay in your tab. It works offline.

About the Htaccess Generator

.htaccess is Apache configuration that lives in a folder rather than in the main config, which makes it the only way to change server behaviour on most shared hosting. It can force HTTPS, move URLs, compress responses, set cache headers and lock files away, and it is read fresh on every single request, which is both why it works without a reload and why it is slightly slow.

The snippets that circulate online are the problem this page is for. They are written for different Apache versions, they mix 2.2 and 2.4 access syntax, they leave out the module guards, and they are pasted in whatever order they were found, which for rewrite rules is not a cosmetic issue. A redirect below a front controller rule never runs, and nothing tells you: the page just loads as normal.

So the ordering is fixed here and shown to you. Protocol first, then the host, then trailing slashes, then your redirects, then the front controller, because that is the sequence in which each rule sees the address the previous one produced. Access, compression, caching and headers come after, grouped and guarded. What you get is one file to paste, with comments saying what each block does, so the next person can read it.

Frequently Asked Questions

Order, modules, caching and why nginx cannot use this.

Almost always because your host does not allow one of the directives. Options -Indexes is the usual suspect, since many shared hosts set AllowOverride to forbid it. Restore your backup, then add the sections back one at a time until it breaks; the last one you added is the culprit.

Check whether it sits below a front controller rule. A rule that ends in [L] stops the rewrite pass, so anything after the catch-all that sends requests to index.php never runs. This page writes redirects above the front controller for exactly that reason.

No, and it fails silently rather than with an error: nginx has no per-directory configuration file and never reads it. The same rules have to be rewritten in a server block in nginx.conf and the server reloaded. LiteSpeed does read .htaccess, and IIS uses web.config, which is different again.

Use 301 when the move is permanent, which is nearly always. It passes ranking signals to the new address and browsers cache it hard, which is the catch: a wrong 301 can stay in a visitor's browser for a long time. Use 302 only when the old URL will genuinely come back, such as during maintenance.

It works, and for a handful of addresses it is fine. For anything larger it is the wrong tool: the file is parsed on every request, so a list of hundreds of addresses is a cost paid by every visitor, and the addresses change constantly. A firewall or a rule at your CDN is the better place.