.htaccess Generator
Quick Access to Coding Tools
Go straight to the formatter, validator, encoder, generator, or developer utility you need.
How to Use the .htaccess Generator
Select the rules you need
Select the rules you need.
Configure redirect URLs
Configure redirect URLs.
Set caching and security options
Set caching and security options.
Copy the generated .htaccess code
Copy the generated .htaccess code.
.htaccess Generator — Build Apache Redirect, HTTPS, Caching, and Security Rules
The .htaccess file is Apache's per-directory configuration mechanism — a plain text file you place in your web directory that controls how Apache handles requests for that directory and everything beneath it. It's one of the most powerful tools available to website owners on shared hosting, because it works without access to the main server config. You can redirect URLs, force HTTPS, block directory listing, set cache durations, enable compression, restrict access by IP, and configure custom error pages — all through a single .htaccess file.
This generator assembles the most commonly needed directives into a clean, properly formatted .htaccess file you can copy or download. Everything is generated in your browser; nothing is sent to any server.
URL Rewriting and Redirects with mod_rewrite
mod_rewrite is Apache's most powerful module for URL manipulation. It provides a rule-based engine that matches incoming request URLs against patterns and rewrites or redirects them based on conditions. Nearly every PHP framework and CMS depends on it.
WordPress pretty permalinks: WordPress's URL rewriting — turning /?p=123 into /my-post-title/ — is handled entirely by rewrite rules in .htaccess. WordPress writes these rules automatically when you save permalink settings, but understanding they route all non-file, non-directory requests to index.php helps when troubleshooting 404 errors after restructuring.
Laravel front-controller routing: Laravel requires all HTTP requests funneled through public/index.php. The .htaccess in public/ checks whether the requested path maps to an actual file or directory, and if not, rewrites to index.php. This is the standard front-controller pattern — and the most common source of "everything returns 404" errors when migrating a Laravel app to a new server.
301 vs. 302 redirects: A 301 permanent redirect tells browsers and search engines the old URL has moved permanently, passing accumulated ranking equity to the new URL. A 302 temporary redirect preserves the old URL in search indexes. Use 301 for permanent restructuring; use 302 for temporary maintenance pages or A/B tests.
Common pitfall — redirect loops: An HTTPS redirect that doesn't check the proxy header creates an infinite redirect loop when the site sits behind a CDN. If your site is behind Cloudflare or AWS ALB, use %{HTTP:X-Forwarded-Proto} !https instead of %{HTTPS} off. The proxy terminates SSL before Apache sees the request, so %{HTTPS} is always "off" even for HTTPS visitors.
Gzip Compression and Browser Caching
Gzip via mod_deflate: Compresses text-based HTTP responses before sending them to the browser. HTML, CSS, JavaScript, JSON, XML, and SVG typically compress 60–80%. For a page with 200KB HTML and 300KB JavaScript, gzip reduces the total transfer to under 100KB. The browser decompresses transparently. This directly impacts Core Web Vitals — Largest Contentful Paint in particular — and Google's page experience ranking signals.
Browser caching via mod_expires: Sets Cache-Control and Expires headers by file extension or MIME type. Images, CSS, JavaScript, and fonts don't change on every request — setting a long cache duration (1 month for images, up to 1 year for fingerprinted assets) means returning visitors load pages much faster because most assets are already cached locally. A single .htaccess block covers all asset categories.
Performance impact of .htaccess itself: Apache reads .htaccess files on every request, including checking all parent directories up to the document root. This adds overhead. If you have server config access, moving rules to httpd.conf or a vhost config with AllowOverride None eliminates this per-request cost. On shared hosting where .htaccess is your only option, the performance cost is real but the benefits of compression and caching far outweigh it.
Security Rules — Protecting Your Site at the Server Level
Disable directory listing: Without Options -Indexes, Apache displays a file listing for any directory without an index file — exposing your file structure, backup files, and logs to anyone who visits the URL. This is one of the most common security oversights on shared hosting.
Protect sensitive files: .env, composer.json, wp-config.php, and log files should never be publicly accessible. A FilesMatch block denying access prevents direct HTTP access while still allowing PHP to read them on the server.
Custom error pages: Apache's default error pages reveal server software and version information. Custom error pages present a branded experience and prevent information leakage. The ErrorDocument directive maps HTTP error codes to your HTML pages.
IP-based access control: For admin areas, staging environments, or maintenance mode, Require ip blocks restrict access to specific addresses or ranges. Useful for protecting development sites that shouldn't be publicly visible.
Frequently Asked Questions About .htaccess
index.php or index.html. Rules apply to that directory and all subdirectories. You can also place .htaccess files in subdirectories to override or extend rules for specific folders. The file must be named exactly .htaccess (dot, no extension). On Windows, your FTP client or file manager may hide it — verify the upload succeeded.
%{HTTPS} off works when Apache handles SSL directly. Behind a load balancer, CDN (Cloudflare, AWS ALB), or reverse proxy that terminates SSL, Apache always sees HTTP — %{HTTPS} is perpetually "off." Use RewriteCond %{HTTP:X-Forwarded-Proto} !https instead. Check your hosting provider's documentation for the correct condition — it varies by platform.
mod_rewrite not enabled on the server, directives requiring a module not installed on your host, or AllowOverride restrictions in the server config that block .htaccess from taking effect.
.htaccess on every request, traversing parent directories to the document root. This per-request overhead is real. If you have server config access, moving rules to httpd.conf or a vhost file with AllowOverride None eliminates it entirely. On shared hosting where .htaccess is your only option, the overhead is acceptable — the compression and caching benefits vastly outweigh the filesystem lookup cost.
.htaccess is Apache-specific. Nginx ignores these files entirely — or serves them as plain text if they're not protected. If migrating from Apache to Nginx, you need to translate your .htaccess rules into equivalent Nginx server and location block directives. Use the Nginx Config Generator tool for that purpose.
RewriteCond %{HTTP_USER_AGENT} rules. However, serious bots and scrapers rotate user agent strings — blocking one agent name doesn't block the actual scraper. IP-based blocking via Require ip is more reliable for specific bad actors, and robots.txt is the standard way to communicate crawling preferences to well-behaved bots. .htaccess user-agent blocking is a supplementary measure, not a primary defense.
.htpasswd file (use an online htpasswd generator or the htpasswd command) and place it outside the web-accessible directory. Then add AuthType Basic, AuthName, AuthUserFile (pointing to the .htpasswd file), and Require valid-user to the .htaccess in the directory you want to protect. This provides basic HTTP authentication — the browser shows a username/password dialog. For production use, consider more robust authentication systems that handle session management, rate limiting, and brute-force protection.