Skip to content
RunStack
htpasswd Generator

htpasswd and bcrypt generator

Basic auth for nginx and Apache: a .htpasswd line, config and hash verification. Strictly client-side.

PrivacyHashing runs in your browser. The password is never sent to Runstack servers, put in the URL, or stored.
Algorithm

The .htpasswd format

One line per user: the name, a colon and the password hash. The hash prefix tells the server the algorithm: $2y$ is bcrypt, $apr1$ is Apache's MD5 scheme, {SHA} is Base64 SHA-1. The web server must be able to read the file, but keep it outside the document root, e.g. /etc/nginx/.htpasswd with mode 640 and group www-data.

Basic auth and HTTPS

The browser sends the login and password in the Authorization header as Base64 on every request — encoding, not encryption. Use basic auth only over HTTPS and never reuse a password from another service.

FAQ

Which algorithm should I use for .htpasswd?

bcrypt if the server supports it: Apache 2.4.4+ and nginx on systems with libxcrypt (Debian 11+, Ubuntu 22.04+, RHEL 9) or musl (Alpine). apr1 works everywhere, but it is MD5 with 1000 rounds — much faster to brute-force. Avoid {SHA}.

What bcrypt cost should I pick?

10–12 is enough for basic auth. Each step doubles the verification time, and nginx checks the password on every request with an Authorization header, so 14 will noticeably load a busy server.

Is the password really not sent to the server?

Yes. The hash is computed by the page's JavaScript (bcryptjs and the Web Crypto API); there are no network requests with the password, and it is not put in the URL or browser storage. You can confirm this in the Network tab of the developer tools.

How do I add a user to an existing file?

Append the line (echo 'user:hash' >> /etc/nginx/.htpasswd) or run htpasswd without -c — the -c flag recreates the file and drops all other users. nginx does not need a reload: the file is read on each request.