htpasswd Generator (bcrypt, MD5-APR1, SHA1)
Generate Apache htpasswd password entries with bcrypt, MD5-APR1, or SHA1 — hashed entirely in your browser, plus a ready .htaccess snippet.
Hash algorithm
Higher cost = slower to crack, but slower to generate. Cost 12 can take a few seconds per password.
Privacy
Hashed 100% in your browser. Your password never leaves this page — no network requests, no trackers, no server logs. You can verify this in your browser's devtools network tab.
htpasswd generator online (bcrypt, MD5-APR1, SHA1 — hashed in your browser)
Password-protecting a directory on Apache or Nginx starts with a .htpasswd file: a list of username:hash lines where each password is stored as a one-way hash, never in plain text. The classic way to make one is the htpasswd command on a server — but most people generating these entries do not have shell access, or do not want to paste a password into some random website and hope it is not logged. This generator solves both: pick bcrypt, MD5-APR1, or SHA1, and the hashing happens entirely in your browser with JavaScript. Your password never leaves the page.
That last point is the whole reason this tool exists. Hashing a password is a computation, not a lookup — there is no technical need for a server to be involved. Many htpasswd generators submit your password to a backend (or claim not to, with no way to verify). Here you can open devtools, watch the network tab, and see zero requests while a bcrypt hash is computed. For a tool whose entire job is handling secrets, verifiable privacy is not a nice-to-have; it is the feature.
bcrypt vs MD5-APR1 vs SHA1, explained
The three algorithms on offer are not interchangeable — they come from different eras of password security:
- bcrypt ($2y$) — use this for anything new. Designed for passwords: it is deliberately slow and includes a cost factor you can raise over time as hardware gets faster. Apache 2.4+ understands $2y$ hashes. The 72-byte input limit is a Blowfish quirk worth knowing but rarely relevant.
- MD5-APR1 ($apr1$) — the legacy Apache default. This Apache-specific variant of MD5 was the standard htpasswd hash for years and still works everywhere. But MD5 is fast, and fast is bad for password hashing: a single GPU can try billions of candidates per second. Fine for low-value staging sites; not for anything that matters.
- SHA1 ({SHA}) — the oldest option. A single unsalted SHA-1 digest, base64-encoded. It exists because very old systems expect it. There is no reason to choose it for a new setup.
The practical rule: if your server runs Apache 2.4 or newer, choose bcrypt at cost 10. If you are stuck on ancient infrastructure that only understands $apr1$, use that — and plan the upgrade.
What the cost factor actually does
bcrypt's cost factor is an exponent: the work doubles with each increment. Cost 4 finishes in milliseconds (fine for testing, useless for protection); cost 10 takes a fraction of a second on a modern machine; cost 12 takes a few seconds. That delay is the point — it applies to attackers too, multiplying the price of every guess. Pick the highest cost your login flow tolerates without annoying real users. Because hashing runs in your browser here, you will feel cost 12 yourself: the tool shows a “Hashing…” state so the page stays responsive while it works.
How to use the entries: 3 steps
- Generate. Enter a username and password (or let the tool invent a random 16-character one), choose bcrypt, and copy the username:$2y$… line — or use Bulk mode for whole teams at once and download the finished .htpasswd file.
- Upload. Place the .htpasswd file on your server outside the public web root whenever possible, so it can never be fetched over HTTP even by accident.
- Protect. Drop the generated .htaccess snippet into the directory you want to guard, set AuthUserFile to the file's real server path, and adjust the AuthName (the text browsers show in the login prompt). No Apache restart needed.
A note on the .htaccess snippet
The snippet uses AuthType Basic, which sends credentials with every request — always pair it with HTTPS, otherwise the password travels in easily-decoded base64. Require valid-user admits anyone listed in the file; swap it for Require user alice bob to admit only specific accounts. On Nginx the same .htpasswd file works with the auth_basic_user_file directive instead.
Need the passwords themselves first? ToolsOfWeb's Password Generator creates the strong random passwords worth hashing, and the Diceware Passphrase Generator makes memorable ones from real words.
FAQs
Is it safe to paste my password into this htpasswd generator?+
Yes. Hashing runs 100% in your browser using JavaScript — the password never leaves the page. There are no network requests during hashing, no trackers, and no server logs. You can confirm this by watching the network tab in your browser devtools while generating.
Which htpasswd hash should I choose: bcrypt, MD5-APR1, or SHA1?+
Choose bcrypt ($2y$) for anything new — it is deliberately slow, which makes brute-force attacks expensive. MD5-APR1 ($apr1$) is the legacy Apache default and still works everywhere, but it is fast to crack. SHA1 ({SHA}) is the oldest option and the weakest. If your server supports bcrypt (Apache 2.4+), always prefer it.
What does the bcrypt cost factor do?+
The cost factor controls how much CPU work hashing takes — each +1 doubles the time. Cost 10 takes a fraction of a second; cost 12 takes a few seconds. Higher cost means an attacker must spend proportionally more to guess passwords. Cost 10 is a solid default; use 11–12 for high-value accounts if your server can tolerate the login delay.
Where do I put the .htpasswd file and the .htaccess snippet?+
Upload the .htpasswd file to your server — ideally outside the public web root so it can never be downloaded — then place the .htaccess snippet in the directory you want to protect, with AuthUserFile pointing at the file’s real server path. Restarting Apache is not required; .htaccess is read per request.
Why does bcrypt only use the first 72 bytes of my password?+
That is a property of the Blowfish cipher bcrypt is built on — input is truncated at 72 bytes. For typical passwords this never matters, but avoid relying on characters past byte 72 for extra security. Very long passphrases are better served by hashing schemes without this limit.
More free tools
Want guides and tips? Visit the ToolsOfWeb blog or go back to the homepage.
Related guide