.htpasswd Generator
Build an Apache or nginx username:hash credential line — bcrypt or apr1 — in your browser. Nothing is ever sent anywhere.
.htpasswd lineNothing leaves your browser. The username and password are hashed on your own device — bcrypt via a vendored, pinned library and apr1 in-page. There are no network requests, no logging and no analytics on this tool. Disconnect from the internet and it still works.
What a .htpasswd line is
HTTP Basic authentication protects a directory by checking a username and password against a flat file, conventionally named .htpasswd. Each line is one account written as username:hash — the first colon separates the two fields, and the hash is a one-way, salted digest of the password, never the password itself. When someone logs in, the server hashes what they typed with the salt stored inside the line and compares; the plaintext is never kept on disk. This tool builds one such line for you without the password ever leaving the page.
bcrypt vs apr1 — which to pick
The two schemes below are both salted (so two users with the same password get different hashes), but they differ enormously in how expensive they are to crack once a .htpasswd file leaks:
| Algorithm | Prefix | Salt | Speed | Verdict |
|---|---|---|---|---|
| bcrypt | $2a$ / $2y$ | 128-bit | Deliberately slow (tunable) | Recommended |
| apr1 | $apr1$ | ~48-bit | Fast (1000 MD5 rounds) | Legacy only |
bcrypt is the modern choice: its cost factor lets you make each guess as slow as you can tolerate, so even a stolen hash file resists an offline cracking rig. apr1 — Apache's own MD5-based scheme, marked $apr1$ — runs a fixed 1000 rounds of MD5. It is far better than a bare MD5, but it is fast, and modern hardware tries billions of MD5 operations per second, so a weak password behind apr1 falls quickly. Reach for apr1 only when you are stuck with an old Apache build that predates bcrypt support (Apache added $2y$ bcrypt in 2.4).
The cost factor, concretely
bcrypt's cost is a power-of-two work factor. A cost of 10 means 2^10 = 1024 internal key-expansion rounds; bumping it to 11 doubles that to 2048, and so on. In this browser tool a cost of 10 takes roughly 50–100 ms per hash; 14 can take over a second, especially on a phone, because JavaScript bcrypt is slower than a compiled server implementation. The important property is symmetry: raising the cost slows a legitimate login by the same factor it slows an attacker's billionth guess. Pick the highest cost your login latency budget allows — 10 to 12 is a sensible range for interactive auth.
Wiring it into your server
Paste the generated line into a file (one account per line) and reference it from your config. In Apache:
AuthType BasicAuthName "Restricted Area"AuthUserFile /etc/apache2/.htpasswdRequire valid-user
In nginx, inside the location or server block:
auth_basic "Restricted Area";auth_basic_user_file /etc/nginx/.htpasswd;
Keep the file outside the document root so it can never be served as a download, and give it tight permissions. Basic auth transmits the username and password base64-encoded (not encrypted) on every request, so it is only private over HTTPS — never rely on it on a plain http:// site.
Common mistakes
- Using apr1 out of habit. Most tutorials still show
htpasswd -c, which historically defaulted to apr1 (or even crypt). Preferhtpasswd -Bfor bcrypt — or just use bcrypt here. - A colon in the username. It silently corrupts the line in some tools; this one refuses it. Passwords may contain colons — only the first colon on the line is the separator.
- Trusting a long password blindly with bcrypt. bcrypt only hashes the first 72 bytes of the password; anything beyond that is ignored. It is plenty for real passwords, but do not assume a 200-character passphrase adds strength past byte 72.
- Serving
.htpasswdfrom the web root. If the file is reachable over HTTP, attackers can download every hash and crack them offline. Store it above or outside the served directory.
Honest limits
Everything here runs locally: bcrypt uses a vendored, pinned copy of the widely-used bcryptjs library (committed under this tool's vendor/ folder, no CDN), and apr1 uses an in-page implementation of Apache's apr_md5_encode that is cross-checked in the test suite against openssl passwd -apr1 reference values. Because bcrypt runs in JavaScript it is slower than a native binary, which is why very high cost factors feel sluggish here even though the resulting hash is identical to one your server would accept. This tool generates and verifies the format of a credential line; it does not manage the file, sync accounts, or evaluate how strong the password you chose actually is — pair it with the password generator for that. And Basic auth itself is coarse: it has no logout, no lockout, and no rate limiting, so for anything beyond simple gatekeeping use a real application login.