.htaccess Generator
Generate common .htaccess rules for your website. Select the options you need and copy the generated code.
Performance
Security
• The .htaccess file should be placed in the root directory of your website
• Make sure mod_rewrite is enabled on your Apache server
• Always backup your existing .htaccess file before replacing it
• Some hosting providers may restrict certain .htaccess directives
How to use .htaccess Generator
- 1
Enter your domain
Type your domain name, such as example.com, in the Domain Settings field.
- 2
Select the rules
Check the options you need, like Force HTTPS, Force or Remove www, GZIP compression, hotlink protection, or custom error pages.
- 3
Add redirects
For URL redirects, enter the old and new paths and choose a permanent 301 or temporary 302 redirect.
- 4
Copy or download
Use Copy to Clipboard or Download .htaccess and upload the file to your site's root directory.
Mastering the Apache .htaccess File
What an .htaccess file actually does
An .htaccess file is a per-directory configuration file for the Apache web server. When Apache is built with AllowOverride enabled, it reads the .htaccess file in the directory it is serving from, plus those in every parent directory, and applies their directives to that request. This lets you change server behavior, redirects, caching, access control, and more, without touching the main server configuration or restarting Apache. The changes take effect on the very next request, which is what makes .htaccess so convenient on shared hosting where you have no access to the main config.
The filename is literally .htaccess, with a leading dot and no extension, and on Unix-like systems the dot makes it a hidden file. It belongs in the directory whose behavior you want to change; most commonly that is the document root of your site. A rule in the root applies site-wide unless a deeper .htaccess overrides it.
Apache only: Nginx and others ignore it
This is the first thing to verify before you write a single rule: .htaccess is an Apache feature. Nginx, the other dominant web server, does not read .htaccess files at all and never will, by design. If your site runs on Nginx, dropping an .htaccess into the root does nothing, and the equivalent redirects, rewrites, and headers must be expressed in the Nginx server block instead. LiteSpeed and a few Apache-compatible servers do understand .htaccess syntax, but Nginx, Caddy, and IIS each use their own configuration formats.
If you are unsure which server you have, check the Server response header, which this site's HTTP Header Viewer can show you. Seeing Apache there confirms .htaccess will work; seeing nginx means you are on the wrong track with this file.
Redirects and canonicalization with mod_rewrite
The most common job for .htaccess is redirecting URLs, which it does through the mod_rewrite module wrapped in a RewriteEngine On block. A simple permanent move uses Redirect 301 from an old path to a new one, while RewriteRule handles pattern-based redirects with regular expressions. The two canonicalization tasks nearly every site needs are forcing a single hostname (either always www or always non-www) and forcing HTTPS, both achieved with a RewriteCond that tests the incoming request followed by a RewriteRule that issues a 301 to the canonical version.
Always use 301 (permanent) for moves you intend to keep, because 301 passes link equity to the destination and tells search engines to update their index. A subtle but important detail is to avoid redirect chains: send http://example.com straight to https://www.example.com in one hop rather than bouncing through https://example.com first. Each extra hop adds latency and slightly dilutes ranking signals, which this site's Redirect Chain Checker can help you spot.
Performance: compression, caching, and the AllowOverride cost
Two .htaccess features give immediate performance wins. GZIP compression, configured through mod_deflate, shrinks text-based responses like HTML, CSS, and JavaScript before they are sent, often cutting transfer size by 60 to 80 percent. Browser caching, set with Cache-Control and Expires headers via mod_expires or mod_headers, tells browsers to reuse static assets like images and fonts instead of re-downloading them on every visit. Together these are some of the highest-impact, lowest-effort speed improvements available.
There is a hidden cost to .htaccess itself, though. Because Apache must check for an .htaccess file in every directory along the path of every request, having AllowOverride enabled adds filesystem lookups to each request. On a high-traffic site you control, moving these directives into the main server configuration and setting AllowOverride None is measurably faster. On shared hosting you usually have no choice, and the convenience outweighs the overhead, but it is worth knowing why .htaccess is discouraged for performance-critical servers.
Security, error pages, and access control
Beyond redirects and performance, .htaccess is widely used to harden and polish a site. Custom error pages, set with the ErrorDocument directive, replace the bleak-prone default Apache error screens with branded pages for 404 and 500 responses, which is better for both users and security. Hotlink protection uses RewriteCond on the Referer header to stop other sites from embedding your images and consuming your bandwidth. You can also send security headers such as X-Frame-Options, Content-Security-Policy, and Strict-Transport-Security through the Header directive.
For access control, .htaccess can restrict a directory by IP address or require a password via .htpasswd, and it can block author-enumeration scans that probe for usernames on content management systems. These controls are genuinely useful, but remember they only run when Apache serves the request through the normal path; combine them with proper application-level security rather than relying on .htaccess alone.
Syntax is unforgiving: test before you trust
The single biggest risk with .htaccess is that a syntax error usually does not fail quietly. Instead it triggers a 500 Internal Server Error for every page under that directory, taking the whole site offline until the file is fixed. There is no compile step and no validation before deployment, so a typo, a missing module, or a directive your host has disabled can break everything instantly. Apache directives are also order-sensitive: rewrite rules are evaluated top to bottom, and a broad rule placed before a specific one can swallow requests the specific rule was meant to catch.
The safe workflow is to always back up the existing .htaccess before changing it, deploy changes during low-traffic windows, and immediately load the site afterward to confirm it still responds. If you see a 500 error, restore the backup first and debug second. When a directive depends on a module like mod_rewrite or mod_deflate, confirm your host has that module enabled, since rules for a missing module can error out.
Frequently asked questions
What rules can this generator create?
What is the difference between a 301 and 302 redirect?
Where do I put the generated .htaccess file?
Does this work on Nginx or other servers?
Is the generated code sent anywhere?
Related tools
Keep going with these handy tools