htpasswd Generator
Generate .htpasswd credential lines for HTTP Basic Auth in Apache and nginx. Use bcrypt for new credentials, switch to Apache MD5, SHA-512, or legacy crypt when an older server requires it, and verify whether a password matches an existing hash. Everything runs in your browser, so the password is not uploaded.
- Eight algorithms, from bcrypt (recommended) to Apache MD5, SHA-512/256-crypt, and legacy SHA-1, crypt, and plaintext
- Runs entirely in your browser, so the password stays on your device
- Adjustable bcrypt cost, a built-in strong-password generator, and bulk mode for a complete .htpasswd file
- Verify mode checks a password against any existing hash and tells you which algorithm produced it
Higher cost means a slower hash that is harder to crack. 10–12 is a sensible default.
Hashed locally in your browser. The password is never uploaded.
Overview
A .htpasswd file is only as reliable as its hash algorithm, salt, and storage path. This tool gives you the modern default, compatibility options for older servers, and a way to check existing credentials without the password leaving the page.
- 01
bcrypt by default
The recommended algorithm for HTTP Basic Auth, with an adjustable cost factor so you can trade speed for resistance to brute force. Output uses the $2y$ prefix that Apache and nginx expect.
- 02
Common compatibility formats
Apache MD5 (apr1) for classic .htpasswd files, SHA-512 and SHA-256 crypt for modern Unix, plus MD5 crypt, SHA-1, traditional DES crypt, and plaintext for older systems that require them.
- 03
Clear security labels
Each algorithm is tagged recommended, strong, legacy, or insecure, so you can separate formats fit for new credentials from weak options kept only for compatibility.
- 04
Verify an existing hash
Switch to verify mode, paste a hash or a full user:hash line, type a password, and the tool tells you whether they match and which algorithm was used — no shell access required.
- 05
Bulk file generation
Paste many username:password pairs and get a complete .htpasswd file in one pass, ready to copy or download, instead of running the CLI once per user.
- 06
A matching command hint
Each result shows the equivalent htpasswd or openssl command, so you can reproduce it on the server or learn the flags as you go.
How to use
Generate a credential line, or a whole file, in a few steps — all without your password leaving the browser.
- 01
Enter the username, then type a password or click the dice to generate a strong one.
- 02
Choose an algorithm. Leave it on bcrypt unless an older server needs a specific format, and set the bcrypt cost if you want a slower, stronger hash.
- 03
Copy the generated username:hash line, or download it straight to a .htpasswd file. For many users, turn on bulk mode and paste one username:password per line.
- 04
Point your server at the file — Apache with AuthUserFile, nginx with auth_basic_user_file — and reload. Use verify mode any time to confirm a password against an existing hash.
Details
The details that make the output safe to ship and easy to trust.
- bcrypt output uses the $2y$ identifier, and crypt hashes match openssl passwd byte for byte, so they drop straight into Apache and nginx.
- bcrypt, apr1, and the crypt formats use cryptographically secure random salts, so the same password normally produces different output.
- The built-in password generator uses the browser crypto API and avoids ambiguous characters like O, 0, l, and 1.
- Verify mode auto-detects the algorithm from the hash prefix and re-checks with the embedded salt, including bcrypt $2a$, $2b$, $2x$, and $2y$ variants.
- Nothing is uploaded or logged. Passwords and hashes are processed in memory and gone when you close the tab.
Use cases
Where a fast, private htpasswd tool earns its place.
-
Protecting a staging site
Drop Basic Auth in front of a staging or internal environment in minutes, with a bcrypt credential ready for the protected .htpasswd file.
-
Locking down an nginx location
Generate a hash for auth_basic_user_file and gate an admin path, a metrics endpoint, or a private download without standing up a full login system.
-
Rotating credentials safely
Regenerate a user line with a fresh strong password and a higher bcrypt cost, then verify the old hash against the old password before you swap it out.
-
Provisioning many users at once
Paste a list of username:password pairs from a spreadsheet or script and get a complete .htpasswd file, instead of scripting htpasswd in a loop.
-
Auditing an inherited file
Use verify mode to confirm which algorithm an existing .htpasswd line uses and whether a known password still matches, before deciding what to upgrade.
-
Migrating legacy Basic Auth
Identify apr1, SHA-1, or DES entries in an older file and replace them gradually with bcrypt or SHA-crypt without a risky one-shot migration.
See also
Need the raw credentials first? Generate one with thePassword Generator , and for one-off digests of arbitrary text theHash Generator covers MD5, SHA, and more.
How .htpasswd and Basic Auth fit together
HTTP Basic Auth is the simplest way to put a username and password in front of a site or a path. The server stores credentials in a flat file, one user per line, with the password kept only as a hash.
-
The file format
Each line is username:hash. Apache reads it through AuthUserFile, nginx through auth_basic_user_file. The hash prefix ($2y$, $apr1$, $6$, {SHA}) tells the server which algorithm to verify against.
-
Why bcrypt is the modern choice
bcrypt is deliberately slow and salted, so guessing passwords offline is expensive. A tunable cost factor lets you raise that expense over time as hardware gets faster, which fixed-cost hashes like MD5 or SHA-1 cannot do.
-
Apache MD5 (apr1) is not plain MD5
The $apr1$ scheme runs MD5 through a thousand salted iterations. It is far stronger than a bare MD5 digest and remains the most portable choice for older Apache builds, though bcrypt is preferred where available.
-
SHA-512 and SHA-256 crypt
The $6$ and $5$ schemes are the salted, iterated crypt formats used by modern Linux logins. nginx and recent Apache verify them happily, making them a strong, dependency-free option.
-
The weak ones, and why they exist
SHA-1 ({SHA}), traditional DES crypt, and plaintext survive only for compatibility with very old software. DES silently ignores everything past the eighth character; plaintext is readable by anyone with the file. Use them only when nothing else is accepted.
-
Salting and verification
Every modern scheme embeds a random salt in the output, so the same password produces a different hash each time. Verification re-runs the algorithm with that embedded salt and compares — which is exactly what verify mode does here.
Best practices
Habits that keep Basic Auth credentials strong and your file clean.
- Default to bcrypt for new credentials, and only fall back to apr1 or crypt when a specific server cannot verify it.
- Never ship SHA-1, DES, or plaintext unless an unavoidable legacy system demands it — they offer little or no protection.
- Raise the bcrypt cost as hardware improves; cost 10–12 is reasonable today, higher for sensitive endpoints.
- Serve .htpasswd over a path the web server cannot expose, and keep file permissions tight so the hashes are not downloadable.
- Always pair Basic Auth with HTTPS, since the browser sends the username and password base64-encoded, not encrypted, on every request.
Limitations
What this tool does, and what it leaves to your server.
- It generates and verifies the hashes for a .htpasswd file. It does not edit a server config, upload the file, or manage who can read it.
- DES crypt only uses the first eight characters of a password, and plaintext is not a hash at all — both are offered for compatibility, not security.
- Verify mode recognises standard hash prefixes; an unrecognised or malformed hash is reported rather than guessed at.
- bcrypt truncates passwords beyond 72 bytes, which is a property of the algorithm itself and applies to every bcrypt implementation.
FAQ
Common questions about htpasswd files, the algorithms, and this tool.
Is my password sent to a server?
No. Every hash is computed in your browser with JavaScript, and the password is held only in memory. Nothing is uploaded, logged, or stored, which is the key difference from server-side htpasswd generators that necessarily receive your password.
Which algorithm should I choose?
bcrypt, unless an older server cannot verify it. bcrypt is salted, deliberately slow, and has a tunable cost. If bcrypt is unavailable, Apache MD5 (apr1) or SHA-512 crypt are strong choices. Avoid SHA-1, DES, and plaintext except for unavoidable legacy compatibility.
Are these hashes compatible with Apache and nginx?
Yes. bcrypt output uses the $2y$ prefix Apache expects, and the apr1, SHA-256, and SHA-512 crypt formats match what openssl passwd and the system crypt produce, so both Apache (AuthUserFile) and nginx (auth_basic_user_file) verify them.
What does the bcrypt cost factor do?
It sets how many rounds bcrypt runs, doubling the work for each step up. A higher cost makes each hash slower to compute, which slows down offline guessing attacks. Cost 10 to 12 balances security and login speed for most sites.
How does verify mode work?
Paste a hash or a full username:hash line and the password to test. The tool reads the prefix to identify the algorithm, re-runs it with the salt embedded in the hash, and compares the result — telling you whether the password matches and which scheme was used.
Can I generate a whole .htpasswd file at once?
Yes. Turn on bulk mode and paste one username:password per line. Every line is hashed with the selected algorithm, and you can copy the result or download it directly as a .htpasswd file.
Do I still need HTTPS with Basic Auth?
Absolutely. Basic Auth sends the username and password base64-encoded on every request, which is trivial to decode. Only HTTPS keeps those credentials private in transit, so never use Basic Auth over plain HTTP.
Related tools
Keep going with the rest of the security and identity toolkit.