.htaccess Generator
Toggle the Apache rules you need — HTTPS redirects, caching, compression, security headers, WordPress permalinks — and copy the ready-to-use .htaccess output.
Redirects
WWW Redirect
Trailing Slash
WordPress
Performance
Security
Miscellaneous
Generated .htaccess
# Disable directory listing
Options -Indexes
RewriteEngine On
# Force HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# WordPress permalink rewrite
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# Enable Gzip compression
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript
AddOutputFilterByType DEFLATE application/javascript application/json application/xml
AddOutputFilterByType DEFLATE image/svg+xml font/woff font/woff2
</IfModule>
# Browser caching
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType text/html "access plus 1 hour"
</IfModule>
# Security headers
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>Always back up your existing .htaccess before replacing it. A syntax error will cause a 500 error. Test in a staging environment first.
Technical Deep-Dive: Apache .htaccess for WordPress
📌 On this page
1. Why .htaccess exists and how Apache reads it
.htaccess (short for "hypertext access") lets you override server configuration on a per-directory basis without editing Apache's main configuration file, which is essential on shared hosting where you don't have access to httpd.conf directly. Apache checks for an .htaccess file in every directory it walks through on the way to serving a request, from the document root down to the requested file's own directory, applying and merging directives along the way — which is why placing an .htaccess file in a subdirectory can override or extend rules set at the root.
2. mod_rewrite and how WordPress permalinks actually work
WordPress's "pretty" permalinks (like /2026/my-post/ instead of /?p=123) are not real files or directories — they are virtual URLs that mod_rewrite intercepts and routes to a single real file, index.php, which then asks WordPress's own internal router to figure out what content to serve based on the URL. The rewrite block generated by this tool implements exactly that: if the requested path isn't an existing real file or directory, fall through to index.php and let WordPress handle it. Without this block, any permalink other than the raw ?p=123 query-string format returns a 404, because Apache has no file matching that path.
3. Gzip/Brotli compression and browser caching, explained
mod_deflate compresses text-based assets (HTML, CSS, JS, SVG, fonts) before sending them over the wire, typically shrinking transfer size by 60-80% for compressible text content — binary formats like JPEG and already-compressed WOFF2 fonts see little benefit and are correctly excluded. mod_expires works differently: it tells the visitor's browser how long it may reuse a cached copy of a resource without re-requesting it, which is why images get a long "1 year" expiry (they rarely change) while HTML gets a short "1 hour" window (content updates frequently) — getting these durations wrong in either direction either wastes bandwidth on unnecessary re-fetches or serves stale content after a real update.
4. Redirect chains: why order and single-hop redirects matter
Each redirect (HTTP→HTTPS, non-www→www, or vice versa) is a separate round trip the visitor's browser must make before finally reaching real content — chaining multiple redirects together (http://example.com → https://example.com → https://www.example.com) triples the network latency before the page even starts loading, and search engines also weight redirect chains as a minor ranking/crawl-budget factor. The rules this tool generates are written to combine into a single redirect where possible (checking HTTPS and www together) rather than stacking sequential hops — a meaningful, measurable speed improvement, especially on mobile networks with higher round-trip latency.
5. Hotlink protection and its tradeoffs
Hotlink protection blocks image requests whose HTTP Referer header doesn't match your own domain, preventing other sites from embedding your images directly (consuming your bandwidth to serve content on someone else's page). The tradeoff: legitimate use cases like RSS feed readers, some social media link-preview crawlers, and certain email clients don't always send a Referer header matching your domain, and can be incorrectly blocked — test thoroughly after enabling this, particularly if your content gets shared or syndicated through third-party platforms.
6. Testing changes safely
Always keep a copy of your existing, working .htaccess before replacing it — a single syntax error (an unclosed <IfModule> tag, a malformed RewriteRule) can take down the entire site with a 500 Internal Server Error until it's fixed. Test on a staging copy of the site first when one is available, and after deploying to production, immediately verify a handful of representative URLs (homepage, a blog post, a category archive, an image) load correctly before considering the change complete.
Frequently Asked Questions
What is an .htaccess file?
.htaccess is an Apache web server configuration file placed in a directory to control how the server handles requests for that directory and its subdirectories. It is commonly used for URL redirects, access control, security headers, caching rules, and enabling mod_rewrite for WordPress pretty permalinks.
Is it safe to edit .htaccess on a live WordPress site?
Yes, with caution. Always back up your current .htaccess before making changes. A syntax error can cause a 500 Internal Server Error. Test changes in a staging environment first. The default WordPress .htaccess block should not be removed.
Why does WordPress need .htaccess?
WordPress uses Apache's mod_rewrite module (configured in .htaccess) to route all requests through index.php. This enables pretty permalink structures like /blog/my-post/ instead of /?p=123. Without the WordPress rewrite block, permalinks and most URL structures break.
What is the HSTS header in .htaccess?
HTTP Strict Transport Security (HSTS) tells browsers to always connect using HTTPS for a specified duration, even if the user types http://. It prevents SSL stripping attacks. The max-age value is in seconds — 31536000 = 1 year.
Why does my host say "IfModule not found" or the rules seem to do nothing?
This tool wraps most performance and security blocks in <IfModule> tags precisely because not every Apache installation has every module (mod_deflate, mod_expires, mod_headers) enabled — if a module is missing, the <IfModule> block is simply skipped rather than causing an error. If an entire section (like Gzip compression or browser caching) appears to have no effect, contact your host to confirm the corresponding module is enabled, since some budget shared-hosting plans disable modules by default.
Will this work on Nginx instead of Apache?
No — .htaccess is an Apache-specific mechanism (and LiteSpeed, which maintains Apache compatibility including .htaccess support). Nginx uses a completely different configuration syntax in server blocks (nginx.conf or site-specific conf files) and does not read .htaccess files at all by default. If your host runs Nginx, you will need the equivalent directives translated into Nginx's location/rewrite syntax — typically something your hosting provider or a system administrator configures directly.
What order should multiple .htaccess rule blocks be placed in?
Apache processes .htaccess top to bottom, and RewriteRule directives are order-sensitive within a RewriteEngine block — generally, redirects (HTTPS, www, trailing slash) should come before the WordPress permalink rewrite block, since you want the URL fully normalized before it falls through to WordPress's own routing. This tool generates blocks in a safe, tested order automatically; if you manually merge additional custom rules, insert redirects before the WordPress block, not after.