⚙️ .htaccess Generator
Toggle checkboxes to build a production-ready Apache .htaccess in real time: HTTPS redirect, HSTS, gzip / brotli, cache headers, secret file deny, WordPress permalinks and more.
🔒 About Privacy
- ・All generation runs entirely inside your browser
- ・Domain names and settings are never sent to any server
- ・No logs, no tracking, no database
🧩 Choose features
📄 Generated .htaccess
📖 Where people get stuck
Generates an .htaccess combining HTTPS redirection, www canonicalization, PHP version selection for Japanese shared hosts, cache control, security headers and access restrictions. Everything runs in the browser. An .htaccess has a dangerous property no other configuration file shares — one wrong line and everything under that directory returns 500 immediately. And the error page does not tell you the cause. If your admin panel lives in the same tree, you cannot fix it from there — before you edit, make sure you have a way back.
| Case | What happens | What to do |
|---|---|---|
| One wrong line turns the whole site into a 500 | An .htaccess is re-read on every request, so a mistake affects every request from the moment you save. The most common cause is a directive belonging to a module that is not loaded — write Header set ... where mod_headers is disabled and Apache cannot parse the line, so it returns 500 Internal Server Error. The awkward part is that this is not "the syntax is fine but it does not work" but "the configuration is unreadable so everything stops". All you see is a generic error page, and it does not state which line or what about it is wrong — that information exists only in the server error log. On shared hosting where you cannot see the log, isolating the cause becomes trial and error. |
Always wrap module-dependent directives in <IfModule>. Put them inside <IfModule mod_headers.c> and an environment without the module simply ignores them rather than returning 500 — that alone prevents most incidents. As for process, always take a copy before editing, and edit through a route that still works while the site is returning 500, such as SSH or FTP — editing it from the WordPress admin screen is demolishing the floor you are standing on. Add in small pieces and check in the browser after each one — add ten lines at once and hit a 500 and you are reduced to a binary search. On shared hosting, find out in advance whether you can read the error log, so you are not stuck when it matters. |
| Redirect loops, and a 301 you cannot take back | Writing forced HTTPS and www canonicalization together produces an infinite loop depending on the order of the conditions. Especially where a load balancer or CDN sits in front: the request always arrives at the server over HTTP, so %{HTTPS} stays off forever and the redirect repeats endlessly — the symptom is ERR_TOO_MANY_REDIRECTS. And the nature of a 301 compounds this: 301 means permanent, so browsers cache it aggressively and keep performing the old redirect even after you fix the configuration. The result is the state where you fixed it and it is still broken, and you go on changing the configuration and make things worse — the pattern that costs the most time in this class of problem. |
Behind a proxy, look at %{HTTP:X-Forwarded-Proto}. Writing RewriteCond %{HTTP:X-Forwarded-Proto} !https gives you a correct decision even through a CDN. And always verify with curl -I rather than a browser — curl does not cache redirects, so you always see the result of the current configuration. While building, use 302, confirm the behaviour is what you intended, and only then change it to 301 — that ordering alone avoids essentially every cache-induced incident. If you have already served a wrong 301, the only remedy is to serve a fresh 301 to the correct destination — you cannot clear anyone browser cache from your side. And keep redirect rules in one place — spread across several .htaccess files and your application settings, the source of a loop becomes untraceable. |
A subdirectory .htaccess cancels the parent rules |
An .htaccess applies hierarchically, but mod_rewrite rules alone are replaced rather than inherited. The moment you write a single RewriteRule in a subdirectory, the parent rewrite rules stop applying in that directory — forced HTTPS and www canonicalization both go dead there and nowhere else. What makes it hard to notice is that other directives — authentication, caching, headers — inherit normally, producing the counter-intuitive behaviour of only some things being inherited. Relatedly, a subdirectory may need a RewriteBase, and forgetting it makes relative paths resolve against the parent path, causing 404s or loops. |
Where possible, do not use .htaccess at all; write the configuration in the main server config. On a VPS or a dedicated server you can put it in a <Directory> block — which is also faster, since the per-request search-and-read of the file disappears (with AllowOverride None, Apache does not even look). Where shared hosting leaves you only .htaccess, consolidate the rewrite rules into one parent file and avoid putting any RewriteRule in subdirectories. If you truly need one, RewriteOptions Inherit carries the parent rules through, but it changes the order in which they apply, so verify every pattern by actually requesting it. |
Security headers do not make you secure by being present. X-Frame-Options and Content-Security-Policy close off specific attack techniques and do nothing about vulnerabilities in your application — raising a scanner score and actually being safe are different things. Content-Security-Policy in particular will break your own JavaScript if you get it wrong — start with Content-Security-Policy-Report-Only, watch what it reports, and only then switch to the enforcing header. Also, access restrictions in .htaccess apply only when the file is served through Apache — in a setup where nginx serves static files directly in front, the .htaccess is never read at all. Keeping confidential files outside the public directory is the proper answer; hiding them with an access rule is the fallback. And, easily forgotten: keep the .htaccess itself under version control — a configuration file where nobody knows who added what, or when, is one that eventually nobody dares to touch.
📖 How to Use
-
1
Pick featuresTick the checkboxes for the features you need (HTTPS redirect, HSTS, gzip, etc). The preview on the right updates live.
-
2
Set your domainIf you enable www canonicalization, set your domain (e.g. example.com). Not required for HTTPS-only redirects.
-
3
Copy or downloadUse the buttons to copy to clipboard or download as a file. Always review before uploading.
-
4
Upload to your serverPlace the file as .htaccess in your document root (public_html / htdocs / public). Back up any existing file first.
❓ Frequently Asked Questions
Does .htaccess work on servers other than Apache?
What if I get a 500 error?
Does it work on shared hosting (Xserver / Sakura)?
🔗 Related Tools
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.