Htpasswd Generator
Create a user entry with a bcrypt hash and wire it into Basic Auth with one directive in .htaccess.
-
1Enter data
Enter content, paste text or load a file from disk. -
2Click the button
The tool will immediately process your data in the browser. -
3Get the result
Copy the finished text or save the file to your device.
return "Result ready in 0.1s";
}
Rate this tool:
Related tools
Other tools you may find usefulHtpasswd generator - a password for Basic Auth in Apache and Nginx
The htpasswd generator produces a single line in the user:hash format, ready to paste into a .htpasswd file. The password is hashed with bcrypt, optionally with the older Apache SHA-1 format {SHA}, and the server asks for it when somebody opens the protected directory.
What this tool actually does
You enter a username and a password, pick an algorithm and get one entry. The username may contain letters, digits, a dot, an underscore and a hyphen; a colon is rejected, because inside the file it separates the login from the hash. The password itself is never stored and never recorded in history: only the hash is computed and only the hash goes back to your browser. Every click returns a different bcrypt hash, because a random salt is mixed into the password - all of them verify the same password.
A strong password is a click away in the password generator, and you can match an existing entry against a password in the bcrypt hash checker.
Where the .htpasswd file belongs
Never in a public directory. If the file ends up inside public_html, one configuration slip is enough for the server to hand it out as plain text and leak every hash through a browser. Keep it one or two levels above the DocumentRoot, for example /home/user/private/.htpasswd. Keep the permissions narrow: write access for the owner, read access for the server user, nothing for everybody else.
Why bcrypt instead of MD5, crypt or SHA-1
The .htpasswd format accepts several algorithms, and they differ by orders of magnitude in resistance to offline cracking. Once the file leaks, only one thing matters: how expensive it is to test one password candidate.
| Algorithm | Entry starts with | Verdict |
|---|---|---|
| bcrypt | $2y$12$ | Recommended: tunable cost, salt inside the hash, deliberately slow |
| MD5 APR1 | $apr1$ | The htpasswd default, but 1000 MD5 rounds are not enough today |
| SHA-1 | {SHA} | No salt, a single pass - compatibility only |
| crypt DES | 13 characters, no prefix | Uses only the first 8 characters of the password, broken |
| plaintext | the password in the clear | Never use it |
This tool emits bcrypt with cost 12, which means 4096 key-expansion rounds. For comparison, htpasswd -B defaults to cost 5. Apache has supported bcrypt since version 2.4.4. Note that bcrypt only looks at the first 72 bytes of a password, so the tool rejects longer input instead of silently cutting off the tail. For other hash functions, use the cryptographic hash generator.
The .htaccess entry step by step
- Save the generated line in a
.htpasswdfile outside the public directory. - In the directory you want to protect, create an
.htaccessfile with the four directives from the example below. - Give
AuthUserFilea full filesystem path, never a URL or a relative path. - Check that the host allows
AllowOverride AuthConfig; without it Apache never looks at your file. - Reload the page. The browser shows a login prompt, and a wrong password returns status 401.
AuthType Basic AuthName "Protected area" AuthUserFile /home/user/private/.htpasswd Require valid-user
The AuthName string appears in the browser prompt and defines the realm, so use it to describe the resource, not the password. For a broader directory configuration, reach for the .htaccess file generator.
Basic Auth without HTTPS sends the password in the clear
Authorization: Basic header carrying login:password encoded in base64, and base64 is an encoding, not encryption. Anyone watching the traffic reads the password with one command. Expose such resources over HTTPS only.The header also travels with every request, so during one visit the password crosses the network dozens of times. Basic Auth has practically no log-out: the browser remembers the credentials until the window closes. You can check your certificate in the SSL certificate checker.
The same setup in Nginx
Nginx reads the very same file format, only the configuration differs: inside a server or location block you write auth_basic "Protected area"; and auth_basic_user_file /home/user/private/.htpasswd;. There is one catch. Nginx implements APR1 on its own and delegates every other format to the system crypt() function. Bcrypt therefore works only where the system library knows it, that is on distributions built on libxcrypt. On an older server pick SHA-1 in the tool. Exceptions for single paths are easy to assemble in the location block configurator.
Frequently asked questions
Why does the bcrypt hash change on every run?
Because bcrypt mixes a random salt into the password and stores that salt inside the resulting string. Two hashes of the same password look completely different and both verify correctly. If the hash were always identical, a single rainbow table would crack every user at once.
How do I add more users to the file?
Each user is a separate line in the login:hash format. Generate them one by one and paste them underneath each other, with no blank lines and no spaces around the colon. Logins have to be unique, because Apache uses the first matching entry and silently ignores duplicates.
Is my password kept anywhere?
No. The password is used only to compute the hash during the request. We do not store it in a database, in files or in the tool history - only the algorithm you selected is recorded.
Apache returns a 500 error or never asks for a password. What should I check?
Usually it is a wrong path in AuthUserFile or a file the server user cannot read. The second suspect is AllowOverride None in the virtual host configuration, which makes Apache skip the .htaccess file silently. The third is bcrypt on a server older than Apache 2.4.4. The error log always names the actual reason.
Is .htpasswd enough to protect an admin panel?
As an extra layer in front of an application login it works well, because it turns bots away before any PHP code runs. On its own it has gaps: no lockout after failed attempts, no second factor, no way to log a user out. For sensitive panels add application-level authentication, an IP allowlist and rate limiting.