What is .htaccess?
.htaccess is a configuration file read by the Apache web server. It holds directives (instructions) that change how Apache behaves for the directory it sits in and every folder below it. Site owners commonly use it for redirects, password protection, custom error pages, and forcing HTTPS.
More About .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. Deeper files usually take precedence, but not by one universal rule: whether a directive replaces, merges with, or inherits what a parent directory set depends on the directive and the module behind it. Apache’s configuration sections guide covers the merge rules.
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 served straight from your server
- Block specific visitors by IP address or referring site
- Stop Apache from listing a folder’s contents when it has no index file
All of these work only where the server permits them. Managed and control-panel hosts typically enable overrides for exactly this reason: .htaccess is usually the only way customers without root access can change how Apache behaves.
DreamHost web hosting is one of them: your site runs on Apache with .htaccess honored, so you can add redirects, password protection, and IP blocking yourself, no root access needed. The DreamHost help center keeps a dedicated .htaccess customizations section for the specifics.
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 short for “hypertext access”: on the NCSA server that Apache grew out of, the file’s original job was controlling who could open a directory’s files, and the name stuck as its uses widened. It’s also only Apache’s default; 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 costs 4 extra file-system checks per request, even when no .htaccess file exists anywhere. That count assumes overrides are enabled all the way from the filesystem root, which Apache notes is not usually the case. 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 WordPress .htaccess file.
Frequently Asked Questions
How do I create a .htaccess file if my site doesn’t have one?
Create a plain-text file named exactly .htaccess, with no .txt extension and no other name, then upload it to the directory you want it to control. Any plain-text editor works. Add one directive, save, and reload your site to confirm nothing broke.
Can a website have more than one .htaccess file?
Yes. Every directory can hold its own .htaccess file, and Apache applies them from higher directories toward deeper ones. Whether a deeper file replaces, merges with, or inherits a parent’s settings depends on the directive and module. Password-protecting one folder while leaving the rest open works this way.
Do I need to restart Apache after editing a .htaccess file?
No. Apache reads .htaccess files on every request, so a change takes effect the next time a page loads. That cuts both ways: a mistake shows up immediately too, so check your site right after saving.
Is .htaccess necessary?
No. Apache serves a site fine without one; the file only matters when you need a per-directory change, like a redirect or password protection, and you don’t have root access. WordPress on Apache creates one automatically for pretty permalinks; on Nginx the file doesn’t exist at all.
