How to password-protect a folder

Password-protecting a folder puts a login prompt in front of it at the server level, before any page inside it is even served. It is the right tool for a staging copy of a site, an internal tool, or any folder that needs to be kept away from casual visitors and search engines without building a login system into the site itself.

How it is different from a CMS login

A CMS login screen is part of the application — the server has already served the page, and the application itself decides whether to show content or ask for credentials. Directory-level password protection happens a step earlier: the web server checks for valid credentials before your site's code runs at all, which means it works identically regardless of what is inside the folder, whether that is a CMS, a static page, or a folder of files with no application behind them whatsoever.

Using your control panel

Most control panels include a directory privacy feature that handles this without needing to create or edit any files by hand. Open the relevant section, select the folder to protect, and set a username and password. This is the recommended approach for most people, since it avoids editing configuration files directly and any risk of a small mistake breaking the folder's behaviour.

Doing it manually with .htaccess and .htpasswd

If you want more direct control, or your situation needs something the control panel tool does not cover, the same protection can be set up with two files. First, an .htpasswd file containing the username and an encrypted version of the password, placed somewhere outside the folder being protected and, ideally, outside the publicly accessible part of your site entirely. Second, an .htaccess file inside the folder you want to protect:

AuthType Basic
AuthName "Restricted area"
AuthUserFile /full/server/path/to/.htpasswd
Require valid-user

AuthUserFile needs the full server path to the file, not a web address — check your control panel's file manager for the correct path format if you are unsure. Require valid-user accepts any username and password combination listed in the file, checked against the encrypted value stored there.

Testing it properly

Visit the protected folder directly in a private or incognito browser window, which starts with no saved credentials. Confirm a login prompt appears before any page content is shown, and that an incorrect password is rejected rather than silently allowed through. If nothing prompts at all, double-check the .htaccess file is actually inside the folder you meant to protect, and that the file path in AuthUserFile is exactly correct — a wrong path is the most common reason this setup silently does nothing.

Protecting more than one folder, or adding more users

The same .htpasswd file can list multiple username and password pairs, one per line, if more than one person needs their own separate credentials rather than sharing a single login. To protect several separate folders, either place a matching .htaccess file in each one pointing at the same shared .htpasswd file, or use a different file for each folder if the groups of people who should have access differ between them.

Removing protection later

Once a staging site goes live, or a folder no longer needs restricting, remove the AuthType, AuthName, AuthUserFile and Require lines from the .htaccess file, or use the same control panel tool to disable it if that is how it was set up. Leaving protection in place on a folder that is meant to be public is a common, easily missed cause of a page that inexplicably prompts visitors for a login they were never given.

What this does and does not protect against

This stops casual access and keeps content out of search engines, and it is a genuine barrier for anyone without valid credentials. It is basic authentication, sent with each request, so make sure it is only ever used on a page served over HTTPS — otherwise the credentials themselves are sent in a form that could be read by anyone on the network path, which defeats the purpose entirely. Every hosting plan includes a free certificate for exactly this reason, so there is no reason to run this over an unencrypted connection.