UtilitiesHub

.htaccess Generator

Generate Apache .htaccess snippets for compression, caching, HTTPS, redirects, and security. The file below updates as you change options. Always test on a staging server before production.

Used when “Custom error pages” is checked. Leave blank to use defaults shown in placeholders.

Path redirects

Match a path segment (no leading slash). Example: old-blog/post → /blog/post or a full URL.


Explore More

Go straight to the formatter, validator, encoder, generator, or developer utility you need.

Coding Tools

.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 a directory on your web server that controls how Apache handles requests for that directory and everything underneath it. It's one of the most powerful configuration tools available to website owners on shared hosting, because it works without access to the main Apache server config. You can redirect URLs, force HTTPS, block directory listing, set browser cache durations, enable Gzip compression, restrict access by IP, and configure custom error pages — all through a .htaccess file in your document root.

This generator assembles the most commonly needed directives — organized by purpose — into a clean, properly formatted .htaccess file you can copy directly into your project or download. Everything is generated in your browser; nothing is sent to any server.

URL Rewriting and Redirects with mod_rewrite

mod_rewrite is the most powerful and most used Apache module accessed through .htaccess. It provides a rule-based URL rewriting engine that can match incoming request URLs against patterns and rewrite or redirect them based on conditions. Nearly every PHP framework and CMS relies on it.

WordPress pretty permalinks: WordPress's URL rewriting — turning /?p=123 into /my-post-title/ — is entirely handled by rewrite rules in .htaccess. WordPress writes these rules automatically when you save your permalink settings, but understanding that they route all non-file, non-directory requests to index.php helps when troubleshooting permalink issues.

Laravel/PHP front-controller routing: Laravel's router requires that all HTTP requests be funneled through public/index.php. The .htaccess in Laravel's public/ directory does exactly this — it checks whether the requested path corresponds to an actual file or directory, and if not, rewrites the request to index.php.

Custom redirects: Permanent (301) and temporary (302) redirects can be defined with Redirect or RewriteRule directives. A 301 redirect from an old URL to a new one is essential for preserving SEO value when you restructure your site — it tells search engines and browsers that the old URL has permanently moved, and passes accumulated ranking equity to the new URL.

www to non-www (or vice versa) normalization: Having both www.example.com and example.com serve the same content creates a duplicate content problem for SEO. A rewrite rule that permanently redirects one form to the other ensures all traffic and link equity consolidate on your canonical domain.

Forcing HTTPS — and the Proxy Exception

Redirecting all HTTP traffic to HTTPS is a baseline requirement for any site that handles user data or wants to rank competitively in search engines — Google has used HTTPS as a ranking signal since 2014. The standard .htaccess HTTPS redirect checks %{HTTPS} off and redirects to the HTTPS equivalent of the current URL.

However, this condition fails in a common setup: when your site is behind a load balancer, CDN (Cloudflare, AWS CloudFront), or reverse proxy that terminates SSL before the traffic reaches Apache. In this architecture, the connection Apache sees is always HTTP — even for visitors who connected over HTTPS — because the proxy stripped the SSL. The correct condition in this environment is %{HTTP:X-Forwarded-Proto} !https, which checks the forwarded protocol header instead. The generator includes both options, with a note about when each applies.

Gzip Compression and Browser Caching

Gzip compression via mod_deflate compresses text-based HTTP responses before sending them to the browser. HTML, CSS, JavaScript, JSON, XML, and SVG files all compress dramatically — typically 60–80% reduction in transfer size. The browser decompresses transparently. For a page with 200KB of uncompressed HTML and 300KB of JavaScript, gzip can reduce the total transfer to under 100KB. The impact on page load speed, especially on mobile connections, is significant. This also directly affects Core Web Vitals scores (Largest Contentful Paint in particular) and Google's page experience ranking signals.

Browser caching via mod_expires and Cache-Control headers tells browsers how long to store static assets locally. Images, CSS files, JavaScript bundles, 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 the page much faster because most assets are already in their browser cache. The .htaccess cache rules apply headers by file extension or MIME type, covering all relevant asset categories in one block.

Security Rules — Directory Listing, Access Control, and Error Pages

Disable directory listing: By default, if Apache receives a request for a directory that has no index file, it displays a list of all files in that directory. This exposes your file structure, backup files, log files, and any other files in that directory to anyone who visits the URL. The Options -Indexes directive disables this — visitors see a 403 Forbidden response instead of a file listing.

Protect sensitive files: Files like .env, composer.json, wp-config.php, and log files should never be publicly accessible. A FilesMatch block denying access to these file patterns prevents direct HTTP access while still allowing them to be read by PHP on the server.

Custom error pages: Instead of showing Apache's default error pages (which reveal the server software version and configuration details), custom error pages present a branded experience and can include navigation to help users find what they were looking for. The ErrorDocument directive maps HTTP error codes to custom HTML pages.

IP-based access control: For admin areas, staging environments, or maintenance mode, Require ip blocks (in Apache 2.4) or Allow/Deny directives (in older Apache 2.2) restrict access to specific IP addresses or ranges. This can also be used to deny access to known bad actors or scrapers.

Frequently Asked Questions About .htaccess

Place it in your website's document root — the same directory as your index.php or index.html. Rules in that file apply to that directory and all subdirectories. You can also place .htaccess files in subdirectories to override or extend rules for that specific folder. The file must be named exactly .htaccess (starting with a dot, no extension) — on Windows, your FTP client or file manager may hide it; make sure it's uploaded correctly.
The standard %{HTTPS} off condition works when Apache handles SSL directly. If your site is behind a load balancer, CDN (Cloudflare, AWS ALB), or reverse proxy that terminates SSL before passing traffic to Apache, the connection Apache sees is already HTTP — so %{HTTPS} is always "off" even for HTTPS visitors. In this case, check the X-Forwarded-Proto header instead: RewriteCond %{HTTP:X-Forwarded-Proto} !https. Check your hosting documentation for the correct condition.
A syntax error or conflicting rewrite rule is the most common cause. First, rename or remove the new .htaccess file to restore access. Then add the generated rules incrementally — one section at a time — and test after each addition to isolate which section causes the problem. Common culprits are rewrite rules that create redirect loops (e.g. HTTPS redirect conflicting with an existing rule), mod_rewrite not being enabled on the server, or directives that require a module not installed on your host.
Yes — Apache reads .htaccess files on every request, including checking all parent directories up to the document root. This adds a small overhead per request. If you have access to the main Apache config (httpd.conf or a vhost config file), it's more efficient to put rules there with AllowOverride None to disable .htaccess entirely. On shared hosting where you only have .htaccess access, the performance impact is usually acceptable and the benefits of compression, caching, and redirects outweigh the overhead.
No. .htaccess is an Apache-specific feature. Nginx does not read or process .htaccess files at all — it simply ignores them or serves them as plain text files if not protected. If you're moving from Apache to Nginx, you need to translate your .htaccess rules into equivalent Nginx server and location block directives in the Nginx config file. Use the Nginx Config Generator tool for that purpose.