Htpasswd Generator
This htpasswd generator produces a .htpasswd line for Apache or nginx basic authentication, hashing the password in your browser with the Web Crypto API so it is never transmitted.
Hashed in your browser with the Web Crypto API - the password is never transmitted. Produces the {SHA} format understood by Apache and nginx.
About Htpasswd Generator
Enter a username and a password and you get back a single line, user:{SHA} followed by a base64 digest, ready to append to a .htpasswd file. Apache reads that file through AuthUserFile, nginx through auth_basic_user_file, and both understand the {SHA} prefix. The reason to do this in the browser rather than on someone else's server is straightforward: a password typed into a remote generator has been disclosed to whoever operates it, and you have no way to know what was logged.
HTTP Basic authentication is defined by RFC 7617. The client sends the username and password base64-encoded in an Authorization header on every single request, which is encoding rather than encryption, so the scheme is only defensible over TLS. The stored side has its own weakness. The {SHA} scheme is one unsalted SHA-1 pass, so the same password always yields the same digest, two users sharing a password are visible as identical lines, and anyone who obtains the file can attack it with precomputed tables at enormous speed. There is no work factor to slow that down.
The digest is computed with crypto.subtle.digest and base64-encoded in the page, so the password never leaves your device and nothing is retained here. Use the result where basic auth is a convenience: a staging host, a metrics endpoint, an internal dashboard already behind a VPN. For anything reachable from the internet, generate the file with htpasswd -B instead. That produces salted bcrypt with a tunable cost factor, which Apache supports natively and nginx accepts wherever the platform's crypt() does, and it is far slower to brute-force than unsalted SHA-1.
How to use it
- 1Type the username you want, for example admin.
- 2Type the password in the second field; it is masked and never sent anywhere.
- 3Select Generate to compute the digest in your browser.
- 4Copy the resulting user:{SHA} line and append it to your .htpasswd file, one line per user.
- 5Point Apache at the file with AuthUserFile, or nginx with auth_basic_user_file, then reload the server.
- 6Serve the protected location over HTTPS only, because basic auth credentials travel on every request.
Common use cases
- -Protecting a staging site or preview environment from crawlers and casual visitors before launch.
- -Restricting a Prometheus, Grafana or status endpoint that has no authentication of its own.
- -Adding a user to an existing .htpasswd file when the htpasswd binary is not available on the machine you are working from.
- -Generating credentials for an internal dashboard on a laptop where installing Apache utilities is not an option.
- -Locking down a temporary file-sharing directory behind a reverse proxy for a short-lived handover.
Frequently asked questions
- How do I create a .htpasswd file without the htpasswd command?
- Generate the line here and write the file yourself. Each entry is username:hash on its own line, and Apache and nginx read the same format, so a text editor and one line per user is all it takes. Reference the file with AuthUserFile in Apache or auth_basic_user_file in nginx, then reload. The password is hashed in your browser, not on our servers.
- Is HTTP basic authentication secure?
- It is only as secure as the transport. RFC 7617 sends the username and password base64-encoded in a header on every request, so over plain HTTP they are effectively in clear text, and the scheme itself has no logout, lockout or rate limiting. Over HTTPS, with a strong password and a slow hash on disk, it is acceptable for internal or staging use, not as a primary user-facing login.
- What does {SHA} mean in a .htpasswd file?
- It is a scheme prefix in the RFC 2307 style: the rest of the field is the base64 of a single SHA-1 pass over the password, and both Apache and nginx recognise it. It is unsalted and fast, so identical passwords produce identical strings and a stolen file can be attacked with precomputed tables. Treat it as adequate only behind other controls.
- Should I use bcrypt instead of SHA for htpasswd?
- Yes for anything internet-facing. Run htpasswd -B, optionally with -C to raise the cost, and you get a salted bcrypt hash with a deliberate work factor that makes offline guessing orders of magnitude slower. {SHA} has neither salt nor work factor, which is why this tool states that plainly instead of presenting the two as equivalent. Keep {SHA} for cases where convenience outweighs the risk.