.htaccess Generator

What Is an .htaccess File?

An .htaccess file (the name is short for “hypertext access”) is a per-directory configuration file read by the Apache web server. When Apache receives a request, it looks for an .htaccess file in the requested directory and applies any directives it finds, letting you change how the server behaves without touching the main httpd.conf configuration or restarting the server. Because of this, .htaccess is the standard way to configure Apache on shared hosting, where you usually do not have access to the global config.

The directives you can place in an .htaccess file cover a wide range of behavior: rewriting and redirecting URLs through mod_rewrite, sending HTTP response headers through mod_headers, compressing responses with mod_deflate, controlling browser caching with mod_expires, blocking access to sensitive files, and defining custom error pages. Many of these directives are wrapped in <IfModule> blocks so they are skipped safely if the relevant Apache module is not loaded, which is exactly how this generator structures its output.

How to Use This .htaccess Generator

Work through the option groups in the left panel and watch the generated file build itself in real time on the right. The Redirects section forces HTTPS, adds or removes the www prefix (these two are mutually exclusive), and enforces trailing slashes. The Security section blocks dotfiles and dot-directories like .env and .git/ anywhere in the URL path (but keeps /.well-known/ open), disables directory listing, removes the version footer from Apache’s error pages, and adds hardening headers such as X-Frame-Options, X-Content-Type-Options, HSTS, and a referrer policy. The Performance section enables GZIP compression, sets browser-caching Expires headers (HTML and JSON are checked again on every visit), and removes ETags. You can also turn on CORS (with an optional custom origin), add as many 301/302 custom redirects as you need, and define custom 404, 403, and 500 error pages. If an entry would not work the way you expect (a redirect without a leading slash, an error page given as a full URL, a CORS origin with a path), a hint appears below the output.

To move quickly, use the preset buttons: “Security Preset” ticks the recommended hardening options, “Performance Preset” enables the speed options, and “Everything” turns on all options except Force www, CORS, and HSTS preload, because those depend on your site. When the output looks right, click Copy to grab the whole file, then save it as .htaccess in your site’s directory. “Reset All” clears every option to start over.

Real-World Use Cases

• Forcing HTTPS site-wide — Redirect every HTTP request to HTTPS so visitors and search engines always use the secure version of your site.
• Hardening a site’s security — Add clickjacking, MIME-sniffing, and HSTS headers and block access to hidden files in one step with the security preset.
• Speeding up page loads — Enable GZIP compression and long-lived cache headers so browsers download less and revisit assets from cache.
• Migrating old URLs — Add 301 redirects from retired paths to their new locations so links and rankings are preserved after a site restructure.
• Branded error pages — Point 404, 403, and 500 errors at your own designed pages instead of Apache’s plain defaults.

Tips for Writing .htaccess Rules

• Always back up your existing .htaccess before replacing it; a single bad directive can return a 500 error for the whole directory.
• Set HSTS only once you are confident HTTPS works everywhere, because browsers will refuse plain HTTP for the duration of the max-age you specify.
• Choose www or non-www as your canonical host and redirect the other consistently — running both splits your SEO signals.
• Use 301 (permanent) redirects for moves that are final and 302 (temporary) only when the original URL will return.
• Test changes on a staging copy or low-traffic page first, since Apache applies .htaccess immediately to every request in that directory.

Features

• HTTPS and www redirects — Force HTTPS, add or strip www, and enforce trailing slashes.
• Security headers — Generate X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and HSTS (preload only if you ask for it) inside an <IfModule mod_headers.c> block.
• File and listing protection — Block dotfiles and dot-directories such as /.git/, disable directory listing, and remove the version footer from error pages.
• Checks your input — Hints for redirects, error pages, and CORS origins that Apache or the browser would not accept as intended.
• Performance rules — Enable GZIP compression, Expires caching headers, and ETag removal.
• CORS support — Add cross-origin headers with a wildcard or a custom origin.
• Custom redirects and error pages — Add unlimited 301/302 redirects and set 404, 403, and 500 pages.
• Presets and live preview — One-click security, performance, or everything presets with instant output.
• 100% client-side — Your data never leaves your browser.

Frequently Asked Questions

Where do I put the .htaccess file?

Save the generated rules in a file named exactly .htaccess (with the leading dot and no extension) and place it in the directory you want it to govern, usually your site’s root alongside index.html or index.php. The rules then apply to that directory and every subdirectory beneath it, unless a nested .htaccess overrides them.

Does .htaccess work on Nginx?

No. The .htaccess mechanism is specific to the Apache web server. Nginx does not read per-directory configuration files; instead you add equivalent directives to your nginx.conf or the relevant server block and reload the configuration. The concepts (redirects, headers, caching) carry over, but the syntax is completely different.

Will an .htaccess file slow my site down?

Apache reads and parses the .htaccess file on every request, so on very high-traffic sites there is a small overhead, and the recommended approach is to move the rules into the main server configuration where they are loaded once. For typical websites the impact is negligible and the convenience of per-directory configuration outweighs it.

What does “Force HTTPS” actually do?

It adds a mod_rewrite rule that checks whether the request arrived over plain HTTP and, if so, issues a 301 redirect to the same URL on https://. This ensures visitors and search engines always land on the encrypted version of your pages, which is important for both security and SEO.

What is HSTS and should I enable it?

HSTS (HTTP Strict Transport Security) sends a header telling browsers to only ever connect to your site over HTTPS for a set period, preventing downgrade and cookie-hijacking attacks. Enable it only after HTTPS is fully working across your whole site, because the policy is cached by the browser for the entire max-age and cannot be easily undone once sent. The generated header includes includeSubDomains, so every subdomain must work over HTTPS as well. The preload flag is a separate option and off by default: it only has an effect after you submit your domain at hstspreload.org, and getting it removed from the browsers’ built-in list takes months.

How does the dotfile rule block .git?

Many generators use <FilesMatch "^\.">. FilesMatch only looks at the file name, the last part of the path. A request for /.git/config is checked as config and goes through, so anyone can download your repository and its history. This generator uses RedirectMatch 404 /\.(?!well-known/) instead: it looks at the whole URL path and answers 404 whenever a part of it starts with a dot. /.well-known/ stays reachable because Let’s Encrypt and security.txt need it. Check it after uploading: https://your-site/.git/config should return 404.

Why is there no X-XSS-Protection option?

The header switched on the XSS filter of old browsers. Chrome removed that filter in version 78 (2019), Edge dropped it in 2018, and Firefox never had one. The filter itself could be abused to leak information from a page, so OWASP now recommends not sending the header at all (or sending 0). Real protection against cross-site scripting comes from a Content-Security-Policy, and that has to be written for your own site, so it is not part of a generic .htaccess.

Why are HTML pages not cached for a week?

With a long Expires time, browsers keep showing the old page after you change it, without asking the server. The generator gives HTML, JSON, and XML zero seconds: the browser keeps a copy but checks with the server before using it, which is cheap thanks to Last-Modified. Images and fonts rarely change and get a year, CSS and JavaScript a month. When you change a stylesheet or script, rename the file or add a version like ?ver=2 so visitors get the new one.

Why are the rules wrapped in IfModule blocks?

Directives like header, compression, and caching rules depend on specific Apache modules (mod_headers, mod_deflate, mod_expires). Wrapping them in <IfModule> tags means Apache only runs them when the module is available and silently skips them otherwise, so your site will not crash with a 500 error on a server where a module is not installed.