What is .htaccess?

How .htaccess works

Apache calls .htaccess a “distributed configuration file.” Instead of keeping every setting in one central file, Apache lets each directory carry its own: the directives in a .htaccess file apply to the folder it sits in and to every subdirectory below it. Apache reads these files on every request, not once at startup, checking each directory in the request’s path and applying what it finds.

There’s one big catch. The AllowOverride setting controls whether .htaccess files are honored at all, and Apache’s default is None, which means the files are ignored completely until the host enables them. So when a new rule has no effect, the cause is often the host’s setting rather than your syntax. Ask your host whether overrides are enabled before you go hunting for a typo.

Common .htaccess uses

Site owners reach for .htaccess when they need Apache to do something the default setup doesn’t. The most common jobs:

• Redirect traffic from an old URL to a new one
• Password-protect the whole site or a single directory
• Serve custom error pages, such as your own 404 page
• Force visitors onto HTTPS instead of HTTP
• Block hotlinking, where other sites embed images straight from your server

All of these work only where the server permits them. Managed and control-panel hosts typically enable overrides for exactly this reason: .htaccess is the only way customers without root access can change how the server behaves.

Where the .htaccess file lives

You can place a .htaccess file in any directory of your site, and its directives govern that directory and every folder below it. Most sites keep one in the web root, the folder that holds the site’s index file. The name is only Apache’s default, too; server admins can rename it with the AccessFileName directive.

Can’t see the file? Names that start with a dot are treated as hidden files, so turn on “show hidden files” (sometimes labeled dotfiles) in your FTP client or your host’s file manager. If it still isn’t there, the site may simply not have one yet. You can create it yourself as a plain-text file named exactly .htaccess.

What .htaccess rules look like

Directives are plain text, one instruction per line. A permanent redirect from an old page to a new one is a single line:

Redirect 301 /old-page/ /new-page/

That sends anyone who requests /old-page/ to /new-page/ with a 301 redirect, the status code that tells browsers and search engines the move is permanent. Serving your own error page instead of Apache’s bare default is just as short:

ErrorDocument 404 /errors/not-found.html

That one answers every request for a missing page with your file at /errors/not-found.html instead of Apache’s built-in message.

.htaccess and WordPress

On Apache servers, WordPress manages part of this file itself. When you save your permalink settings, WordPress writes the rewrite rules that make pretty permalinks work into .htaccess, between the markers # BEGIN WordPress and # END WordPress. It regenerates that block whenever permalink settings change, so manual edits inside the markers get overwritten. Put your own rules outside the markers, and see our beginner’s guide to the WordPress .htaccess file for the file’s default contents and common edits.

.htaccess vs. the main Apache configuration

If you have root access to your server, put directives in the main Apache configuration instead. Apache’s own .htaccess tutorial recommends exactly that: the main configuration loads once at server start, while .htaccess files cost a lookup in every directory of the request’s path on every request. Apache’s example: serving a file from /www/htdocs/example means 4 extra file-system checks per request, even if no .htaccess file exists anywhere. Use .htaccess when you don’t have root access, which is why the file is everywhere on shared and managed hosting. The cost is performance, not money.

.htaccess on Nginx and other web servers

Only Apache and Apache-compatible servers read .htaccess. Nginx has no .htaccess support at all: it ignores the file silently, and the rules have to be translated into the Nginx server configuration by whoever manages the server. Apache-compatible servers such as LiteSpeed do honor .htaccess rules. Check which web server your host runs before you spend an hour debugging a file that can never take effect.

Editing .htaccess safely

Edit .htaccess with a plain-text editor such as Notepad++ or Sublime Text, or in your host’s file manager; word processors add formatting that breaks the file. Download a backup copy before you change anything. One bad line can take the whole site down, and the usual symptom is a site-wide 500 Internal Server Error, because Apache returns a server error when it hits a directive it can’t process or isn’t permitted to honor.

If your site breaks right after an edit, restore the backup. Not sure the file is to blame? Rename it temporarily (to .htaccess.bak, say) and reload the site. If the error disappears, the problem is inside the file: fix the offending line and rename it back. For step-by-step edits and example rules, see our beginner’s guide to the .htaccess file.