🔧 Programming ✅ 100% Free ⚡ Instant

.htaccess / Nginx Config Generator

Tick the rules you need — force HTTPS, redirects, gzip compression, browser caching, security headers, custom error pages — and get ready-to-use config for Apache (.htaccess) or Nginx. Everything generates instantly in your browser.

.htaccess

📖 Where to put this

📁

Apache — save as .htaccess in your site's root directory (or the directory the rules should apply to). Requires AllowOverride All in the Apache config.

⚙️

Nginx — paste inside the relevant server { } block in your site's config file (e.g. /etc/nginx/sites-available/yoursite), then run nginx -t and reload.

⚠️

Always test on a staging environment first — incorrect rewrite rules can break your entire site.

🧩 Apache Modules Used

mod_rewriteURL rewriting and redirects

mod_deflateGzip compression

mod_expiresBrowser caching headers

mod_headersCustom HTTP response headers

🔗 Related Tools

What is a .htaccess File?

A .htaccess file ("hypertext access") is a configuration file used by the Apache web server that allows directory-level configuration without editing the main server config — useful on shared hosting where you don't have access to the global config. Common uses include forcing HTTPS, setting up redirects, enabling compression, configuring browser caching, adding security headers, and customising error pages. Nginx doesn't use .htaccess files (by design, for performance reasons) — equivalent rules are placed directly in the server's site configuration file.

This tool generates configuration entirely in your browser — nothing is uploaded or sent anywhere.

How to Use This Tool

Choose your server — Apache (.htaccess) or Nginx — the syntax differs significantly between them.
Tick the rules you need — force HTTPS, www redirects, gzip compression, caching, security headers, custom error pages, directory listing, and more.
Fill in any details — some rules need extra info, like your domain name for redirects or which file extensions to compress.
Copy or download the generated config and add it to your server.

Why These Rules Matter

Force HTTPS — redirects all HTTP traffic to HTTPS, required for SEO, browser trust indicators, and protecting user data in transit.
Gzip/Brotli compression — can reduce text-based asset sizes (HTML, CSS, JS) by 60-80%, significantly improving load times.
Browser caching — tells browsers to reuse static assets (images, CSS, fonts) instead of re-downloading them on every visit.
Security headers — headers like X-Frame-Options, X-Content-Type-Options, and Content-Security-Policy protect against clickjacking, MIME-sniffing attacks, and XSS.
Custom error pages — branded 404/500 pages improve user experience when something goes wrong.

Frequently Asked Questions

The most common cause is that AllowOverride is set to None in the main Apache configuration for that directory — .htaccess files are completely ignored unless AllowOverride All (or specific directives) is enabled. Other causes: the required Apache module (mod_rewrite, mod_deflate, mod_expires, mod_headers) isn't enabled, or there's a syntax error causing a 500 Internal Server Error — check your server's error log for details.

On Ubuntu/Debian, run sudo a2enmod rewrite then restart Apache with sudo systemctl restart apache2. On shared hosting, mod_rewrite is almost always already enabled — if rewrite rules aren't working, the issue is more likely AllowOverride or a syntax error in your rules.

Unlike Apache's .htaccess (read on every request), Nginx loads its configuration once at startup for performance. After editing a config file, run sudo nginx -t to test for syntax errors, then sudo systemctl reload nginx to apply changes without dropping active connections.

Yes — if you add a force-HTTPS redirect before installing a valid SSL certificate, visitors will be redirected to an HTTPS URL that fails to load (or shows a security warning). Install and verify your SSL certificate first (many hosts offer free Let's Encrypt certificates), confirm HTTPS works correctly, and only then add the force-HTTPS redirect rule.

Both compress text-based responses (HTML, CSS, JS, JSON) to reduce transfer size. Brotli generally achieves better compression ratios than gzip, especially at higher compression levels, and is supported by all modern browsers. However, gzip is more universally supported by older clients and is simpler to enable since mod_deflate is more commonly available than Brotli's mod_brotli on shared hosting.

Yes, particularly Content-Security-Policy (CSP) and X-Frame-Options. CSP can block inline scripts, external fonts, or third-party widgets (analytics, chat widgets, embedded videos) if they're not explicitly allowed in the policy. X-Frame-Options can break legitimate iframe embeds of your site. Test thoroughly after adding security headers, starting with report-only modes for CSP where supported.

Copied!