htpasswd Generator

Generate a .htpasswd line for HTTP Basic authentication in Apache or Nginx. Pick bcrypt (the modern, recommended choice), APR1-MD5 (Apache's traditional format), or SHA-1, enter a username and password, and copy the user:hash entry. All hashing runs in your browser — the password is never transmitted, which is exactly what you want for a credentials file.

.htpasswd line

How to use the htpasswd Generator

Type the username and password, choose a hashing algorithm, and click generate. For bcrypt, the cost slider sets the work factor — 10 is the modern default, 12 is stronger if you can spare the extra time per login. The output is a single username:hash line. Append it to your .htpasswd file, one entry per user.

Reference the file from your server config — in Apache with AuthType Basic, AuthUserFile /path/.htpasswd, and Require valid-user; in Nginx with auth_basic and auth_basic_user_file. Because each line is independent, you can paste several together to protect a directory with multiple accounts. The password is hashed entirely on this page and never leaves your browser.

The .htpasswd file and its hash formats

HTTP Basic authentication is the simplest way to password-protect a directory on a web server. Credentials live in a flat .htpasswd file, one username:hash pair per line. The server never stores the plain password — only a hash — and on each request it hashes what the browser sent and compares. The format of that hash is what distinguishes the options here.

bcrypt (entries beginning $2y$) is the recommended choice. It is deliberately slow and includes a tunable cost factor, so an attacker who steals the file can only test a few guesses per second per core rather than billions. APR1-MD5 ($apr1$) is Apache's own iterated-MD5 scheme — far better than a bare MD5 because it salts and loops a thousand times, and still widely compatible, though weaker than bcrypt. SHA-1 ({SHA}) is an unsalted single hash; it is fast and supported by Nginx, but offers no protection against precomputed or brute-force attacks and should only be used where compatibility demands it.

Every modern hash here is salted except SHA-1, which is why two users with the same password get different bcrypt and APR1 hashes but identical SHA-1 hashes. For anything new, choose bcrypt; reserve APR1 for older Apache setups that require it, and SHA-1 only for legacy compatibility. Whichever you pick, the security of Basic auth still depends on serving the site over HTTPS, since the password itself travels with each request.

Common use cases

  • Protecting a staging site. Add a quick Basic-auth gate in front of a non-public environment.
  • Nginx and Apache directories. Generate the user file both servers read for auth_basic.
  • Adding users without the CLI. Produce an entry when the htpasswd command-line tool is not handy.
  • Migrating hash formats. Re-issue an account on bcrypt to replace an old MD5 or SHA entry.

Frequently asked questions

Is my password sent to a server?
No. All three algorithms run in JavaScript in your browser — bcrypt and APR1-MD5 in local code, SHA-1 via the Web Crypto API. The password never leaves your device, which is essential when generating credentials.

Which algorithm should I choose?
bcrypt for anything new — it is salted, slow, and has a tunable cost factor. Use APR1-MD5 only for older Apache setups that need it, and SHA-1 only where a legacy system requires that exact format. Avoid plain unsalted hashes for real credentials.

Why is bcrypt shown as $2y$?
Apache htpasswd writes bcrypt hashes with the $2y$ prefix. The $2a$, $2b$, and $2y$ variants are the same algorithm and Apache and Nginx accept all of them; this tool emits $2y$ to match what htpasswd -B produces.

How do I use the entry?
Append the line to a .htpasswd file, then point your server at it: in Apache use AuthUserFile with Require valid-user; in Nginx use auth_basic_user_file. Add one line per user. Always serve the protected site over HTTPS.

What does the cost factor change?
For bcrypt it sets how many rounds of hashing run — each step up roughly doubles the time. A higher cost makes both legitimate logins and brute-force attacks slower; 10 is a sensible default, 12 is stronger for sensitive systems.