bcrypt, apr1, or SHA-1 — which should I pick?

Pick bcrypt unless you have a specific reason not to. Apache 2.4+ and Nginx both verify bcrypt (`$2y$`) and it is the only scheme here that is genuinely slow to brute-force. apr1 (`$apr1$`) is salted MD5 — it is what the old `htpasswd -m` produces and it still works everywhere, but MD5 is weak, so only use it if your server is too old for bcrypt. SHA-1 (`{SHA}`) is unsalted and fast; it exists purely for legacy systems that demand it. If two users share the same password, SHA-1 produces an identical hash and apr1/bcrypt do not — that alone is a reason to avoid SHA-1.

How do I actually use the file with .htaccess?

Save the output as a file (e.g. `/etc/apache2/.htpasswd`) above your web root, then in your `.htaccess` add: `AuthType Basic`, `AuthName "Restricted"`, `AuthUserFile /etc/apache2/.htpasswd`, `Require valid-user`. For Nginx, put `auth_basic "Restricted";` and `auth_basic_user_file /etc/nginx/.htpasswd;` inside the `location` block. The tool prints both snippets below the output. Pair it with our .htaccess generator to assemble the rest of the file.

Is it safe to type a real password here?

Yes — the hashing happens entirely in your browser. The password, the random salt, and the resulting hash never leave the page, are never sent to any server, and are deliberately never written to the URL or localStorage (only your scheme choice is remembered). That said, the safe habit is to treat any machine you do not control as untrusted: on a shared computer, close the tab when you are done so the password is not left in a form field.

Why does the same password give a different bcrypt/apr1 hash each time?

bcrypt and apr1 prepend a random salt, so re-hashing the same password produces a different string every time — that is correct and intended. The server stores the salt inside the hash and uses it to verify. SHA-1 here is unsalted, so it always produces the same output for the same password (which is exactly why it is unsafe). Do not be alarmed that bcrypt output changes between clicks; any of those values will authenticate the same password.

Can Nginx read bcrypt and apr1 hashes?

Nginx reads apr1 (`$apr1$`), bcrypt (`$2y$`), and SHA-1 (`{SHA}`) in its `auth_basic_user_file`, same as Apache. The one caveat is very old Nginx builds without crypt() bcrypt support on some platforms — if bcrypt verification fails on an ancient server, fall back to apr1. Modern Nginx on Linux handles all three.

Lock a staging site behind Basic Auth before launch

You spun up `staging.example.com` and need it password-walled so Google does not index it and random visitors cannot poke around. Type a username (say `team`) and a strong password, leave the scheme on bcrypt, copy the line into `/etc/nginx/.htpasswd`, then add `auth_basic "Staging";` and `auth_basic_user_file /etc/nginx/.htpasswd;` to the server block. Reload Nginx. Now every request gets a browser login prompt and crawlers see a 401. The whole thing is two lines of config plus one file, and the file never left your laptop on the way to being generated.

Add a second admin to an existing Apache .htpasswd

A teammate needs access to a directory already protected by `AuthUserFile /var/www/.htpasswd`. Rather than reinstall the `htpasswd` CLI on the server, generate just the new user's line here: enter their username and password, copy the single `user:$2y$...` row, and append it to the existing file. Apache reads one user per line, so appending is all it takes — no need to regenerate the others. Keep the scheme consistent with the existing file (bcrypt is fine to mix with apr1 lines; Apache picks the right verifier per row).

Migrate an old SHA-1 htpasswd to bcrypt

You inherited a `.htpasswd` full of `{SHA}` entries and want to move to bcrypt for safety. You cannot convert a hash directly (that is the point of hashing), so you regenerate each line: for every user, ask them for a fresh password, paste username + password here with the scheme set to bcrypt, and rebuild the file row by row. Use the multi-user list so you assemble the whole replacement file in one place, then download it as `.htpasswd` and swap it in.

Protect a single sensitive endpoint on Nginx

You expose a `/metrics` or `/admin` path that should not be public. Generate a one-user `.htpasswd` (bcrypt), drop it at `/etc/nginx/.htpasswd`, and wrap just that location: `location /metrics { auth_basic "Metrics"; auth_basic_user_file /etc/nginx/.htpasswd; }`. The rest of the site stays open. This is the fastest credible gate for an internal dashboard that does not justify a full auth system yet.

Generate test credentials for a CI integration test

Your integration test needs an Apache container with a known Basic-Auth user. Generate a deterministic file locally — pick apr1 if your test fixture expects the classic format, or bcrypt for realism — copy the line into a `Dockerfile` or test fixture, and point `AuthUserFile` at it. Because generation is client-side and offline, you can bake the fixture into the repo without any tool install step in CI, and the password lives only in your test config.

.htpasswd Generator — Apache & Nginx Basic Auth

Generate Apache/Nginx .htpasswd lines — bcrypt, apr1 (MD5), SHA-1 — multi-user, copy, download — 100% browser-only

Runs locally
Category Developer & DevOps
Best for Checking file type, size, metadata, and obvious mismatch signals before sharing.

Runs 100% in your browser. Passwords are never sent anywhere, never written to the URL, and never stored. Only your scheme choice is remembered.

Hash scheme

Recommended. Slow to brute-force, salted. Apache 2.4+ and Nginx both verify it.

bcrypt cost: 10

Username

Password

.htpasswd file

# Add a user to generate the file

Users in file

No users yet — add one above.

Server config snippet

Apache .htaccess

AuthType Basic
AuthName "Restricted"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Nginx location block

location /private/ {
  auth_basic "Restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
}

What this tool does

Build a complete Apache or Nginx Basic-Auth `.htpasswd` file in your browser. Type a username and password, pick a hashing scheme, and get a ready-to-paste `username:hash` line. Three schemes are supported: bcrypt (`$2y$`, the only one Apache 2.4+ and Nginx both consider safe today), apr1 (`$apr1$`, the classic Apache-specific salted MD5 that older `htpasswd` defaults to), and SHA-1 (`{SHA}`, fast but unsalted and deprecated — included only for legacy compatibility). Add as many users as you need; each row is hashed independently and stacked into one file. Copy the whole file with one click or download it straight as `.htpasswd`. Everything runs as plain JavaScript in your tab — the bcrypt core is the same Eksblowfish implementation our bcrypt tool uses, and the apr1/SHA-1 routines are pure client-side too. No password, salt, or generated hash is ever sent to a server, logged, or written to the URL. The tool also prints the matching `.htaccess` and Nginx config snippet so you know exactly which `AuthUserFile` / `auth_basic_user_file` line to add once the file is on your server.

Tool details

Input: Text + Numbers; The page exposes text boxes, numeric controls, file pickers, or structured inputs depending on the tool.
Output: Live result + Copy + Download; The result area focuses on usable output, with copy, download, or preview actions when supported.
Privacy: Browser-side processing; The main tool logic does not call an external API, so inputs normally stay in the current tab.
Save / share: Local preference storage; Preferences, history, or drafts are saved in this browser without an account.
Performance budget: Initial JS <= 32 KB; No WASM budget is declared, keeping the tool quick to open on mobile.
Best fit: Developer & DevOps · Developer; Category and role tags drive related tools, internal links, and quick fit checks.

How to use

1. Input

Paste or drop your content into the tool panel.
2. Process

Click the button. All processing is local in your browser.
3. Copy / Download

Copy the result or download to disk in one click.

How .htpasswd Generator fits into your work

Use it before upload, handoff, archive, support review, or any moment where a file needs one local check before it leaves your machine.

File jobs

Checking file type, size, metadata, and obvious mismatch signals before sharing.
Preparing mixed folders for upload, archive, intake, or review.
Keeping sensitive files in the browser instead of sending them to an account-based service.

File checks

Do not treat the extension alone as proof of the real file type.
Review metadata before a file goes to customers, vendors, or a public page.
Keep the original file until the copied, converted, or exported result is verified.

Good next steps

These links move the current task into a more complete workflow.

Real-world use cases

Lock a staging site behind Basic Auth before launch
You spun up `staging.example.com` and need it password-walled so Google does not index it and random visitors cannot poke around. Type a username (say `team`) and a strong password, leave the scheme on bcrypt, copy the line into `/etc/nginx/.htpasswd`, then add `auth_basic "Staging";` and `auth_basic_user_file /etc/nginx/.htpasswd;` to the server block. Reload Nginx. Now every request gets a browser login prompt and crawlers see a 401. The whole thing is two lines of config plus one file, and the file never left your laptop on the way to being generated.
Add a second admin to an existing Apache .htpasswd
A teammate needs access to a directory already protected by `AuthUserFile /var/www/.htpasswd`. Rather than reinstall the `htpasswd` CLI on the server, generate just the new user's line here: enter their username and password, copy the single `user:$2y$...` row, and append it to the existing file. Apache reads one user per line, so appending is all it takes — no need to regenerate the others. Keep the scheme consistent with the existing file (bcrypt is fine to mix with apr1 lines; Apache picks the right verifier per row).
Migrate an old SHA-1 htpasswd to bcrypt
You inherited a `.htpasswd` full of `{SHA}` entries and want to move to bcrypt for safety. You cannot convert a hash directly (that is the point of hashing), so you regenerate each line: for every user, ask them for a fresh password, paste username + password here with the scheme set to bcrypt, and rebuild the file row by row. Use the multi-user list so you assemble the whole replacement file in one place, then download it as `.htpasswd` and swap it in.
Protect a single sensitive endpoint on Nginx
You expose a `/metrics` or `/admin` path that should not be public. Generate a one-user `.htpasswd` (bcrypt), drop it at `/etc/nginx/.htpasswd`, and wrap just that location: `location /metrics { auth_basic "Metrics"; auth_basic_user_file /etc/nginx/.htpasswd; }`. The rest of the site stays open. This is the fastest credible gate for an internal dashboard that does not justify a full auth system yet.
Generate test credentials for a CI integration test
Your integration test needs an Apache container with a known Basic-Auth user. Generate a deterministic file locally — pick apr1 if your test fixture expects the classic format, or bcrypt for realism — copy the line into a `Dockerfile` or test fixture, and point `AuthUserFile` at it. Because generation is client-side and offline, you can bake the fixture into the repo without any tool install step in CI, and the password lives only in your test config.

Common pitfalls

Putting the .htpasswd file inside the web root. If it sits under a path the server serves, anyone can download your hashes. Keep it above the document root (e.g. `/etc/apache2/.htpasswd`, not `/var/www/html/.htpasswd`) and point `AuthUserFile` at the absolute path.
Choosing SHA-1 because it looks shortest. `{SHA}` is unsalted Base64 SHA-1 — two users with the same password get identical hashes and it falls to a rainbow table instantly. It is here only for legacy compatibility. Default to bcrypt; drop to apr1 only on servers too old for it.
Forgetting that one row equals one user. Each line is `username:hash`. To add a user you append a line; to remove one you delete its line. Pasting a multi-line block where a single line is expected, or duplicating a username, makes Apache use only the first matching row.

Privacy

Every hash — the bcrypt Eksblowfish core, the apr1 salted-MD5 routine, and the SHA-1 digest — is computed by plain JavaScript inside this tab. Your usernames, passwords, the random salts, and the generated `.htpasswd` lines never touch a network, are never logged, and are deliberately kept out of the URL so nothing sensitive lands in a browser history or server access log. Unlike most tools on this site, this one does not sync any input to the shareable URL — there is no "share with result" link for credentials, by design. The only thing remembered between visits is your chosen hashing scheme (bcrypt / apr1 / SHA-1) in localStorage; passwords are never stored. Close the tab on a shared machine to clear the form.

FAQ

Tool combos

Folks in your role tend to reach for these alongside this tool.

Developer

Browse all tools for this role

.htpasswd Generator — Apache & Nginx Basic Auth

What this tool does

Tool details

How to use

1. Input

2. Process

3. Copy / Download

How .htpasswd Generator fits into your work

File jobs

File checks

Good next steps

Real-world use cases

Lock a staging site behind Basic Auth before launch

Add a second admin to an existing Apache .htpasswd

Migrate an old SHA-1 htpasswd to bcrypt

Protect a single sensitive endpoint on Nginx

Generate test credentials for a CI integration test

Common pitfalls

Privacy

FAQ

.htaccess Generator

Bcrypt Generator

Password Generator

robots.txt Generator

.env File Validator

AI Eval Planner

Apache Cheatsheet

API Key Generator

API Rate Limit Cheatsheet

ASCII Table Generator

ASCII Table Reference

awk + sed Cheatsheet