Polyatic .htpasswd Generator

.htpasswd Generator

Build an Apache or nginx username:hash credential line — bcrypt or apr1 — in your browser. Nothing is ever sent anywhere.

Username
Password
Algorithm
bcrypt cost (work factor)10

Your .htpasswd line

Nothing 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:

AlgorithmPrefixSaltSpeedVerdict
bcrypt$2a$ / $2y$128-bitDeliberately slow (tunable)Recommended
apr1$apr1$~48-bitFast (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 Basic
  • AuthName "Restricted Area"
  • AuthUserFile /etc/apache2/.htpasswd
  • Require 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). Prefer htpasswd -B for 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 .htpasswd from 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.