Guide PHP & Development

How to use .htaccess on your hosting account

One file that controls redirects, rewrites and access rules for a whole folder — and one typo in it that can take the site offline.

Updated 7 min read Beginner

.htaccess is a plain text configuration file that applies to the folder it sits in and every folder beneath it, read by the Apache web server layer on every request to that path. It is the standard way a shared hosting account controls behaviour that would otherwise need access to the server's main configuration — redirects, URL rewriting, custom error pages, and basic access restrictions — without needing root access to change anything.

Where it has to live

Placement matters more than anything else about this file. It has to sit in the folder whose behaviour you want to change, and its rules apply to that folder and every subfolder below it unless a more specific .htaccess further down overrides them. For a whole-site rule, that means the file belongs in your document root — the same folder as your site's main index.php or index.html — not one level up or down from it.

It is a hidden file

The leading dot makes .htaccess hidden by default in most file managers and FTP clients. If you cannot see it, look for a "show hidden files" toggle rather than assuming the file does not exist — most sites running on Apache or a compatible layer already have one, often created automatically by a CMS.

The rules it can contain

A handful of directive types cover the overwhelming majority of what .htaccess is actually used for:

  • Redirects — sending one URL to another, permanently or temporarily.
  • Rewrites — turning a clean URL like /products/42 into the query string a script actually expects, invisibly to the visitor.
  • Custom error pages — pointing a status code such as 404 at a specific page instead of the server default.
  • Access control — blocking specific IP addresses, or password-protecting a directory.
  • A limited set of PHP settings — on an older mod_php setup only; see the warning below, because this specific use is the one most likely to have quietly stopped working.

Our companion article, ten .htaccess rules worth knowing, gives working syntax for the most common of these.

Basic syntax rules

Each directive goes on its own line. Rewrite rules need the rewrite engine turned on once at the top of the block that uses them:

RewriteEngine On
RewriteRule ^old-page$ /new-page [R=301,L]

The [R=301,L] flags mean "redirect with a 301 status" and "stop processing further rules if this one matched" — the L flag in particular is easy to forget and is a common reason a redirect appears to half-work while a later rule in the file keeps rewriting the result further.

One syntax mistake can take the whole site down

Apache reads .htaccess on every request to the folder it covers, and a broken line — a missing bracket, an unrecognised directive, a module that is not enabled — produces a 500 error for the entire site, not just the rule that was wrong. Always keep a copy of the working file before editing it, so a mistake is a one-line revert rather than a rebuild from memory. If this has already happened to you, fixing a corrupted .htaccess and fixing a 500 internal server error both walk through recovering from it.

Why a PHP setting in .htaccess might silently do nothing

Older setups running mod_php allowed lines like php_value memory_limit 256M directly in .htaccess, and plenty of tutorials online still show this pattern. Most modern shared hosting, though, runs PHP through PHP-FPM instead — see what PHP-FPM is — and FPM does not read those directives from .htaccess at all. Depending on configuration, the line is either silently ignored or triggers a 500 error outright. Change PHP settings through the PHP settings area of your control panel or a user-level php.ini instead, and reserve .htaccess for what Apache itself handles — redirects, rewrites, access control and error pages.

Testing changes safely

  1. Copy the existing file before editing

    Download or duplicate it under a different name so a working version exists to restore from.

  2. Make one change at a time

    Adding several new rules at once makes it much harder to identify which line caused a problem if one appears.

  3. Reload the site immediately after saving

    Confirm the site still loads before moving on to the next change, rather than batching several edits and testing at the end.

  4. Test in a private browser window

    Redirect rules are often cached aggressively by your own browser, which can make a working new rule look like it has not taken effect at all.

Handled this way, .htaccess is a genuinely useful piece of control for anyone on shared hosting without root access — the caution above is mainly about respecting how immediately and completely a mistake in it can show up, not a reason to avoid it.

Related reading