What does a .htpasswd file do?

A `.htpasswd` stores users plus password hashes for [HTTP Basic Auth](https://en.wikipedia.org/wiki/Basic_access_authentication). One entry per line in the format `username:hash`. Apache references the file in a `.htaccess` via the `AuthUserFile` directive plus `Require valid-user`. The hashes are salted one-way functions — `bcrypt`, `APR1-MD5`, `SHA-1` or the legacy `crypt`. Plaintext is never stored, so a file leak does not directly hand over passwords — a strong hash flavour like bcrypt makes the brute-force path expensive.

Which hash algorithm is safest in 2026?

bcrypt with cost factor 12 is the OWASP 2026 standard and the safest of the four `.htpasswd` algorithms. bcrypt uses an [adaptive cost factor](https://en.wikipedia.org/wiki/Bcrypt) — every step doubles the hashing time, which makes brute force linearly more expensive over time. APR1-MD5 uses 1000 MD5 iterations and is crackable in under a second on 2026 GPU hardware. SHA-1 without iterated salt is completely unsuitable. The `crypt` algorithm (DES-based) accepts only 8-character passwords. bcrypt clearly wins.

Is APR1 MD5 still secure?

APR1 MD5 is considered legacy in 2026, but many setups still accept it. Apache `htpasswd` used APR1 as default for years — the 1000 MD5 iterations were adequate in 2010, but in 2026 they break in seconds with GPU tools like hashcat. APR1 still earns its keep as the nginx compatibility fallback (nginx accepts APR1, rejects bcrypt — see [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)). For new Apache setups: always bcrypt. For nginx: SHA-1 with `{SHA}` prefix or migration to a dedicated auth plugin.

Why doesn't nginx support bcrypt in Basic Auth?

nginx `auth_basic_user_file` has rejected bcrypt for years — see [nginx Issue #1154](https://github.com/nginx/nginx/issues/1154) and the older Ticket #382. The reason: nginx calls the system `crypt()` function, and the combination of glibc versions, BSD variants and musl-libc returns inconsistent results for `$2y$` strings. The nginx maintainers therefore explicitly marked bcrypt as not officially supported. Workarounds: use APR1-MD5 or SHA-1 on nginx, or run an auth module (Lua, OpenResty) that ships its own bcrypt verification. The generator warns automatically when you combine bcrypt with nginx.

Which bcrypt cost factor in 2026?

12 is the OWASP recommendation for 2026 — see [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). Cost factor 12 means `2^12 = 4096` iterations and takes about 250–400 ms per hash on a modern server. That is login-friendly (a user waits a quarter-second) and makes brute force expensive (billions of attempts → weeks). Cost 10 (the Apache htpasswd CLI default) is too weak in 2026. Cost 14 is safer (~1.5 s) but noticeably slow for Basic-Auth login. The generator runs a single-shot benchmark on your device before you hash — you see the actual latency, not a guess.

Does this generator see my password?

No. The password never leaves your browser. There is no `fetch`, no `XMLHttpRequest`, no WebSocket. You can verify this yourself: open F12, switch to the 'Network' tab, set the filter to 'All', enter a password, generate the hash, and you'll see exactly zero outgoing requests. The salt comes from the Web Crypto API (`crypto.getRandomValues`); the hashing runs as pure JavaScript on the main thread or a Web Worker. No `localStorage`, no cookie, no analytics snippet. The ` ` has no `action` attribute, the inputs carry `autocomplete="new-password"` so your browser doesn't cache the plaintext.

How do I add entries to an existing htpasswd?

Copy this tool's output and append it to your existing `.htpasswd` file. A `.htpasswd` is a plain-text format: one entry per line, no header, no sections. If two lines target the same user, Apache takes the first match. To replace an entry, search for the old line in your editor or with `grep -v` and swap it. The generator's batch mode accepts a whole table of users at once and returns a complete block — ideal for team staging setups.

What about crypt_r() failed (22) on nginx?

This error means nginx received a bcrypt hash — switch to APR1 or SHA. `crypt_r() failed (22: Invalid argument)` in the nginx error log appears whenever `auth_basic_user_file` finds a line with a `$2y$` or `$2a$` hash. nginx cannot verify the hash (see [Issue #1154](https://github.com/nginx/nginx/issues/1154)) and throws error 22. Fix: switch the generator's webserver toggle to 'nginx', set algorithm to APR1-MD5 or SHA-1, regenerate the hash, replace the line in `.htpasswd`. Apache servers handle bcrypt fine — this error only shows up on nginx.

htpasswd Generator — bcrypt 12 with nginx warning

What does the htpasswd generator do?

The generator emits Apache .htpasswd lines — pure-client, so your password never leaves the browser. You pick the webserver (Apache or nginx), enter user plus password, and the generator picks the matching hash algorithm by default: bcrypt for Apache, APR1-MD5 for nginx. If you try an incompatible combination (bcrypt on nginx), the warning appears immediately — not when production already shows crypt_r() failed (22) in the error log.

Four hash algorithms are built in, chosen against the 2026 security baseline:

bcrypt — the OWASP default, with cost factor 4 / 10 / 12 / 14 selectable. A single-shot benchmark measures the actual hashing latency on your device before you hash.
APR1-MD5 — Apache legacy plus nginx compatibility. 1000 MD5 iterations with an 8-byte salt.
SHA-1 — {SHA} prefix, no salt, no stretching. Only as nginx fallback when APR1 fails; otherwise discouraged.
crypt (DES) — the original Apache default. Truncates passwords at 8 characters and falls to dictionary attacks trivially in 2026. Historic setups only.

Single mode and batch mode are separate tabs. In batch, you paste user:password lines and receive a complete .htpasswd block — with a per-entry cost-override option. The strength meter shows entropy and heuristic warnings (dictionary hits, common substitutions, keyboard walks) live as you type.

What bcrypt cost factor should you use in 2026?

bcrypt is the only one of the four .htpasswd algorithms still recommended without reservation in 2026. The algorithm dates from 1999, builds on the Blowfish block cipher and uses an adaptive cost factor — every step doubles the hashing time. That makes bcrypt future-proof: if GPU hardware doubles in five years, you bump the cost factor by one and the security margin stays the same.

The OWASP Password Storage Cheat Sheet recommends cost 12 as the minimum for 2026. The Apache htpasswd CLI default is still cost 10 — that was fine in 2014, but it is too weak today. Cost 14 is more conservative (~1.5 s per hash) but noticeably slow for login workflows.

The generator measures actual hashing time on your device before you hash the final password. You see: “Cost 12 = 287 ms in this browser.” That lets you pick a cost factor by latency rather than gut feeling. On a slow mobile browser, cost 11 is plenty; on a modern desktop, cost 13 is often still snappy. Presets: 4 (demos), 10 (Apache CLI), 12 (OWASP), 14 (conservative).

Which algorithm fits Apache or nginx?

Apache mod_auth_basic plus mod_authn_file accept all four algorithms without complaint — the recommended choice is bcrypt. The generator picks that automatically when you select ‘Apache’ above. The matching .htaccess block reads:

AuthType Basic
AuthName "Protected"
AuthUserFile /path/to/.htpasswd
Require valid-user

You can build the matching block in parallel with the .htaccess generator — it ships an HTTP Basic Auth rule with realm and path fields.

nginx is different. auth_basic_user_file calls the system crypt() function and only accepts the hashes crypt() understands: APR1-MD5 ( $apr1$ ), SHA-1 ({SHA}), DES-crypt and plaintext (which you should obviously never use). bcrypt is rejected — the generator’s webserver toggle disables bcrypt automatically for nginx. If you want bcrypt verification on nginx, you need OpenResty with a Lua module or a dedicated auth plugin — both sit outside the Basic-Auth standard directive.

Why is APR1-MD5 deprecated and how do you migrate?

APR1-MD5 plays an odd dual role: legacy on Apache, standard on nginx. The algorithm uses 1000 MD5 iterations with an 8-byte salt — adequate in 2010, crackable in under a second on 2026 GPU hardware. New Apache installs should never reach for APR1; an existing APR1 .htpasswd should be migrated to bcrypt line by line.

Migration steps:

Generate new bcrypt hashes per user (use the generator’s batch mode).
Delete the old APR1 lines from .htpasswd, insert the new bcrypt lines.
Reload .htaccess (Apache reload is enough, no restart needed).
Test the login once per user — Apache verifies both formats in parallel, the switch is transparent.

Migration is harder on nginx because bcrypt is rejected. Three paths: (a) keep APR1 and rotate passwords on a schedule, (b) move to OpenResty plus a Lua auth module, (c) replace Basic Auth entirely with a modern auth system (OAuth2-Proxy, Authelia, Cloudflare Access). Path (c) is the correct long-term answer for 2026 — Basic Auth was never designed as production auth.

How can you verify the password never leaves the browser?

Nobody but you sees this password. The generator has no server endpoint for hashing, no telemetry ping, no cookie, no account. The only Web Crypto API call is crypto.getRandomValues for salt bytes — that runs in the browser, no network call. The bcrypt algorithm is bundled as a pure-JS implementation; APR1, SHA-1 and crypt likewise.

To verify it yourself:

Open the tool, open DevTools (F12).
Switch to the ‘Network’ tab, filter on ‘All’.
Enter a password, generate the hash.
The network tab shows zero requests during hashing — no POST, no WebSocket, nothing.

The form element has no action attribute, the inputs carry autocomplete=\"new-password\" so your browser doesn’t cache the plaintext in form history. Close the tab and the password is gone — the generator persists nothing in localStorage or sessionStorage. If you want an audit, the source code is on GitHub and the lint blocks any fetch call in this tool path.

How does the batch mode help DevOps and team setups?

Batch mode solves the DevOps team-setup scenario: ten developers need access to a staging environment, each with their own password. You paste ten user:password lines into the batch field, pick algorithm plus cost factor, and you receive a complete .htpasswd file — one hash per line, ready to upload to the server.

The strength meter runs per entry so you can immediately spot weak passwords. Optional: per-entry cost override — admin accounts get cost 14, service accounts cost 12. The download button hands you the file in the right format. Combined with the .htaccess generator, you can build a complete HTTP Basic Auth configuration in two tab switches — .htaccess plus .htpasswd, both pure-client.

What is intentionally not built?

No password suggestions — password generation belongs in the dedicated password generator, not in a hash emitter. Mixing both functions would cost trust (‘does the generator see my password?’ FAQ).
No hash cracking — the generator emits, it does not break. To recover a lost hash, use John the Ripper or hashcat locally; no browser tool can do this in reasonable time.
No SSO / OAuth integration — HTTP Basic Auth is its own auth scheme. For modern auth use an OIDC provider, not .htpasswd. The generator serves the classic Basic-Auth use case exactly.
No Argon2 variant — Apache htpasswd does not support Argon2. If you need Argon2, configure a dedicated auth module or move to application-layer auth.

Where can I read more?

Apache htpasswd manual 2.4 — official CLI documentation
OWASP Password Storage Cheat Sheet — hash algorithm recommendations 2026
nginx Issue #1154 — the official bcrypt rejection with reasoning
OpenSSL 3.0 manual — cryptographic primitives behind bcrypt/APR1
bcrypt on Wikipedia — history, algorithm, cost-factor math
MD5 on Wikipedia — why MD5 (and therefore APR1) is unsafe in 2026

.htpasswd Generator — bcrypt 12 with nginx warning

Web server

Algorithm

How It Works

Paste text or code

Instant processing

Copy result

Privacy

How do you use this tool?