What the Htpasswd Generator Does
The Htpasswd Generator produces ready-to-paste lines for Apache's password files. Type the password into the input panel, set the username in the options bar (a Username field defaulting to admin), and the output panel shows the complete line — username:hash — with the password hashed using bcrypt at a fixed cost factor of 10. Drop the line into an .htpasswd file, wire the file into your server config, and the account works.
The tool exists because the format has sharp edges worth automating. An
.htpasswd file is one line per user: username, a colon, and a hash in a specific modular-crypt format. Getting the hash right matters less than getting the
line right — the colon separator, no whitespace padding, one user per line, file permissions — and hand-assembling those lines with a general-purpose hash tool produces subtle breakage. This page emits the whole line, correctly formatted, with the hashing done locally via the same
bcryptjs library the
Bcrypt Generator uses.
Scope note, stated honestly: htpasswd files pair with HTTP Basic authentication, which transmits credentials base64-encoded on every request — readable by anyone on the path unless the connection is HTTPS. The tool generates correct credentials; securing the transport is your configuration's job. Used over TLS for low-friction protection of staging sites, dashboards, and internal tools, the combination remains a sensible staple.
How the Hashing Works
Apache's
htpasswd utility supports several hash formats, and the one this tool emits —
bcrypt in Apache's terminology, enabled with
-B — is the strongest of them. The line looks like
deploy:$2b$10$o73QSXR2PZYtvC.RugDNm.Fb2Qm0LIDjH29rw8VGB7VEU0lI8iZne: username, colon, then the standard 60-character bcrypt string with its
$2b$ variant, cost 10, 22-character salt, and 31-character hash. Everything between the colons is exactly what the
Bcrypt Generator produces — this tool wraps that in the file format and pins the username prefix.
The cost is fixed at 10 rather than configurable, deliberately: htpasswd authentication runs on every request to protected resources, and a cost that made sense for a login endpoint can multiply a protected page's latency. Cost 10 keeps verification in the tens of milliseconds while retaining bcrypt's salt and slowness properties — the same reasoning Apache's own utility applies to its defaults. If you need a different cost for an application-level user table, the Bcrypt Generator handles that case.
A fresh random salt is drawn for every generated line, so generating a line for the same username and password twice produces different-looking lines — both valid, either storable. The property is bcrypt's salt working as designed, and it means an attacker comparing two of your generated lines learns nothing about whether the passwords match.
Verification on the server side mirrors generation: Apache reads the salt and cost from the stored line, re-runs bcrypt with the presented password, and compares. Nothing about the file's format needs to be understood by anything else — which is the format's virtue. Nginx pairs with the same file for auth_basic through Apache-htpasswd-compatible tooling, so the generated lines are portable across the two dominant servers.
What the tool does not do is manage the file itself — no appending, no dedup, no atomic write. Producing the correct line is the automation target; file management (permissions 640, owned by the server user, outside the document root) is the operational half that remains yours, and the checklist belongs in your deployment docs rather than in a hash tool.
Using the Htpasswd Generator
- Step 1 — Enter the password. Type it into the input panel. It stays in the page; nothing is transmitted.
- Step 2 — Set the username. Replace the default
admin in the Username field. Use the exact username your users will type — Basic auth compares it case-sensitively on most servers. - Step 3 — Copy the whole line. Output is
username:hash, ready for the file. One line per user, appended to your .htpasswd. - Step 4 — Create or update the file. First user: create
.htpasswd with the line. Additional users: append lines. Existing user: replace their line (generate a new one — the file cannot be edited in place). - Step 5 — Wire it into the server config. Apache:
AuthType Basic, AuthUserFile /path/.htpasswd, Require valid-user in the relevant scope, with the bcrypt format supported natively. Then confirm the file is not inside the document root (or that the server denies web access to it), and that the site is HTTPS — the credentials ride every request.
Common Use Cases
Protecting staging and preview environments. The classic use: keep crawlers and strangers out of a pre-production site with one config block and one password file, without touching application code.
Basic-auth front doors for internal tools. Admin panels, metrics dashboards, and health endpoints that lack their own auth get a serviceable gate from a single file — pair with HTTPS and IP allow-listing where the stakes justify it.
Rotating a shared credential. When a shared staging password leaks, generating a replacement line and swapping it into the file rotates access in seconds — one of Basic auth's few operational advantages.
Understanding an existing htpasswd file. The format anatomy makes an inherited file legible: which users exist, which hash format their lines use (bcrypt's $2b$ versus older MD5/SHA lines), and which deserve regeneration.
Generating known credentials for CI. Seeding a protected test endpoint with documented credentials for automated checks — generate here, paste into the infrastructure-as-code that owns the file.
Worked Example
Enter the password S3cret!, set the username to deploy, and run:
deploy:$2b$10$o73QSXR2PZYtvC.RugDNm.Fb2Qm0LIDjH29rw8VGB7VEU0lI8iZne
Read it apart: deploy — the username exactly as typed; : — the separator the server splits on; $2b$10$ — bcrypt variant, cost 2¹⁰; then salt and hash in Base64. The line is complete and final — no trailing punctuation, no quoting.
Create the file and lock down the directory in one pass — on the server:
echo 'deploy:$2b$10$o73QSXR2PZYtvC.RugDNm.Fb2Qm0LIDjH29rw8VGB7VEU0lI8iZne' > /etc/apache2/.htpasswd
chmod 640 /etc/apache2/.htpasswd
Run it again with the same inputs: the hash portion differs (fresh salt), and both lines are valid — an instructive moment that the salt is per-generation, not per-password. Note the username is never hashed: Basic auth transmits usernames in the clear-ish (base64) on every request, which is one more reason the HTTPS requirement is not optional.
Tips and Common Mistakes
- One colon, never two. Everything after the first colon is the hash — but bcrypt hashes themselves contain no colons, so a line with two colons means something was pasted wrongly. Regenerate rather than repair.
- The file must not be web-reachable. Inside the document root without a deny rule, a misconfigured server will serve your hashes to anyone. Outside the root, or denied by config, or both.
- HTTPS is not optional. Basic auth sends
base64(user:password) on every request. Over plain HTTP, credentials are readable in transit by anything on the path. The hash protects the file; TLS protects the traffic. - Usernames are not secrets and are not hashed. The line stores them in plaintext so the server can match the presented username. Sensitive usernames (email addresses) in the file are exposed to anyone who reads it — one more reason file permissions matter.
- Replacing a user means replacing their line. Password changes and username changes both regenerate the whole line; there is no in-place edit. Keep the file in version control (without the real password) to make changes reviewable.
- Cost 10 is the tool's fixed choice, on purpose. Every-request authentication penalises over-slow hashes. Application-level password storage with higher costs is the Bcrypt Generator's case, not this one.
Frequently Asked Questions
Which hash format does this tool use?
Bcrypt — Apache's strongest htpasswd format, the one its utility emits with -B. The output line's $2b$10$ prefix identifies variant and cost, and modern Apache (2.4.x with crypt support) and Nginx tooling verify it natively. Older formats the utility also supports — MD5-crypt ($apr1$) and the deprecated plain SHA — are deliberately not offered: bcrypt is available, stronger, and the modern default.Why can't I choose the cost factor?
Because htpasswd verification runs on every request to protected resources, and cost is latency on each one. The tool pins cost 10 — the same reasoning Apache's utility applies — keeping verification fast while retaining bcrypt's salt and slowness. For application-level password storage where the cost-per-login tradeoff differs, use the
Bcrypt Generator with the cost you choose.
Does this work for Nginx?
Yes. Nginx's auth_basic consumes Apache-compatible password files through tooling like htpasswd or openssl passwd, and bcrypt lines verify correctly with the common distributions' packages. The generated line is format-standard; the server that reads it is your choice.Two lines I generated for the same password look different — which is right?
Both. Every generation draws a fresh random salt, so identical passwords produce different stored lines, and either verifies successfully. This is bcrypt's salt property, not an inconsistency. Pick either line; discard the other; do not try to "fix" one to match.Is Basic auth with htpasswd actually secure?
Scoped honestly: the bcrypt hashing protects the password file at rest as well as any application password store, and the mechanism is trivially deployable. The scheme's weakness is transport — credentials ride base64-encoded on every request — so it is only as secure as your TLS, and it lacks rate-limiting, lockout, and MFA by itself. For staging gates and low-stakes internal protection over HTTPS, it is a sensible staple; for real user accounts, application-level auth with proper session management remains the answer.Related Tools