.htaccess Generator — Security Headers & HSTS

What does the .htaccess generator do?

The generator is an editor for Apache configuration rules. You pick from 14 rule kinds (redirects, rewrites, security headers, HTTPS enforcement, cache control, IP block, hotlink protection, HTTP Basic auth and more), tune each rule field by field, and get back a cleanly structured .htaccess — with <IfModule> guards per rule, optional <IfVersion> dual output for legacy shared hosts, and Cloudflare Pages export for _headers and _redirects. Everything runs in the browser. No upload, no account, no cookie banner.

The four presets cover the common stack constellations:

• Modern security headers — CSP starter, HSTS preload-ready, Permissions-Policy, COOP, X-Content-Type-Options, Referrer-Policy.
• Static site — performance — Cache-Control + Expires for JS/CSS/images/fonts, Deflate compression for text MIMEs.
• HSTS preload pipeline — full preparation for the hstspreload.org submission.
• WordPress hardening — protection for wp-config.php, wp-includes, XML-RPC.

Which rule kinds are built in?

Fourteen rule kinds, grouped by function:

• Routing — redirect (301/302/303/307/308), rewrite pattern, www ↔ non-www, enforce HTTPS, add or remove trailing slash.
• Headers — security headers block with CSP, Permissions-Policy, HSTS, COOP, Referrer-Policy.
• Access — IP allow-list (whole site or admin-only), IP block-list, HTTP Basic auth with realm and .htpasswd path.
• Content — custom error documents (401/403/404/500), directory listing on/off, Cache-Control with max-age and immutable, compression with MIME-type list.
• Protection — hotlink protection with referer allow-list.

Each rule displays the Apache modules it needs as badges. You see at a glance whether your host provides mod_rewrite, mod_headers, mod_deflate and friends.

How does the Apache 2.4 vs 2.2 dual mode work?

Most shared hosts run Apache 2.4 in 2026. The access directives changed fundamentally between 2.2 and 2.4: instead of Order Allow,Deny plus Allow from, 2.4 uses the new Require directive. If you deploy to a legacy host, switch on the 2.4+2.2 dual mode — the generator then emits both syntax variants wrapped in <IfVersion> blocks. Apache reads only the matching block, and you do not have to maintain two separate .htaccess files.

The trade-off: <IfVersion> itself needs mod_version, which most 2.4 builds include but not every 2.2 build. The generator therefore wraps the dual blocks in an <IfModule mod_version.c> guard as well.

What does the HSTS preload checklist do?

When you enable the HSTS flag in any security-headers rule, a checklist appears above the rule list. It scans the other rules and reports whatever would block a successful hstspreload.org submission:

• Missing HTTPS redirect? → reported.
• Missing includeSubDomains in the HSTS header? → checked.
• Missing preload flag in the HSTS header? → checked.

If everything is green, the link offers the hstspreload.org submission form directly. This avoids the classic case where a domain is rejected because the submission workflow was not understood.

Which security headers actually matter?

The Mozilla Web Security Guidelines and the OWASP Secure Headers Project list the following headers as the mandatory set for modern web apps. The generator covers all of them:

• Strict-Transport-Security — forces HTTPS in browsers for the next period (1-year max-age default, preload-ready). Mandatory for any site that was ever reachable over HTTP.
• Content-Security-Policy — allow-list for scripts, styles, images, fonts. Prevents cross-site-scripting and mixed-content. Complex to tune, hence the validator hint.
• Permissions-Policy — denies browser APIs (camera, microphone, geolocation, payment request, sensors) the page does not need. Default: everything off.
• Cross-Origin-Opener-Policy — same-origin isolates the window against window.opener tampering and re-enables SharedArrayBuffer (relevant for WebAssembly tools).
• Referrer-Policy — strict-origin-when-cross-origin sends the full referer only to the own domain, only the origin to third parties. Balance between analytics need and privacy.
• X-Content-Type-Options — nosniff prevents MIME-sniffing attacks on files with missing Content-Type header.

The generator wraps all six in a single <IfModule mod_headers.c> block and emits the block as one unit. If you do not need a header, disable the checkbox or empty the textarea — the line falls out of the output automatically.

Which errors come up most often?

Three classics that always show up when a new .htaccess hits production — the generator tries to avoid each:

1. 500 Internal Server Error after upload — almost always a directive without its module loaded. Classic: Header set … on a host without mod_headers. The generator therefore wraps every rule in a <IfModule> guard. If you still see a 500, check your host’s error.log first.
2. Infinite redirect loop on HTTPS enforcement behind a reverse proxy — Cloudflare and similar CDNs forward the request HTTPS-terminated; Apache sees %{HTTPS} as off because the proxy → origin connection is HTTP. Fix: check %{HTTP:X-Forwarded-Proto} instead. The generator emits the standard variant; CDN-fronted sites adjust the condition manually.
3. CSP blocks your own inline scripts — happens when the default CSP without 'unsafe-inline' ships, but the page still contains inline scripts. Two paths: move the inline scripts to separate files (cleaner long-term), or allow the remaining inlines via nonce/hash whitelist. The external CSP evaluator shows exactly which inlines the policy currently blocks.

These three pain points are referenced in the FAQ; the generator cannot prevent them, but it communicates them honestly.

How does the Cloudflare Pages export work?

Cloudflare Pages does not read .htaccess. Instead the platform expects two files in the web root:

• _headers — path pattern plus HTTP response headers. Format: path line + indented Key: Value lines.
• _redirects — source path, destination path, status code per line.

The generator emits both files from the same rule list. Security headers and Cache-Control go into _headers, redirect / enforce-HTTPS / www-canonical / trailing-slash rules go into _redirects. You only switch the output tab.

This solves a common pain point: when migrating from shared hosting to an edge platform you otherwise have to translate .htaccess manually into two different files. The generator does it automatically — same rule list, three output formats.

How is privacy handled?

Pure-client. The generator runs entirely in the browser. There is no server endpoint for rule validation, no telemetry call, no cookie, no account. Closing the tab discards the rule list — the generator persists nothing. If you need a history, download the .htaccess after every edit and version it in the repo, which is where it belongs anyway.

What is intentionally not built?

• No nginx converter — htaccess-to-nginx is a separate tool in the backlog because the directive mappings are too extensive for an inline tab.
• No inline .htpasswd generator — the password-file generator is sibling tool htpasswd-generator (coming). The HTTP Basic auth rule references the required file in the output.
• No mega bot-blocker list — User-Agent sniffing is largely ineffective in 2026 and produces false positives. Bot blocking belongs on the edge in a WAF.
• No server-side validation — would require a server round-trip, breaks the pure-client promise. For live testing the FAQ links to the external madewithlove tester.
• No mod_security ruleset editor — too specialised for a generator tool. Anyone tuning mod_security works directly against the OWASP CRS configuration.

Where can I read more?

• Apache HTTP Server documentation 2.4 — official directive reference
• .htaccess on Wikipedia — history, mechanism, examples
• hstspreload.org — submission list for HSTS preload domains
• CSP Evaluator — external validator for Content-Security-Policy values
• Cloudflare Pages headers docs — _headers syntax reference
• Cloudflare Pages redirects docs — _redirects syntax reference