Developer Tools

.htpasswd File Generator

Generate .htpasswd files for Apache and Nginx Basic Authentication securely in your browser. Supports bcrypt, APR1-MD5, and SHA-1. Passwords are never sent to the server.

Tips

  • Use bcrypt: The most secure algorithm available. Works with Apache 2.4+ and Nginx. Higher cost values slow down hashing and increase resistance to brute-force attacks (10 is a common default).
  • APR1-MD5 ($apr1$) is for compatibility with Apache 2.2 or older. It works with virtually all Apache and Nginx versions.
  • SHA-1 ({SHA}) has low collision resistance and is not recommended. Use it only in legacy environments that require backward compatibility.
  • Place the .htpasswd file outside the DocumentRoot (or Nginx's web root) so that it cannot be accessed directly over the web.
  • Always use HTTPS. Basic Authentication credentials are only Base64-encoded, not encrypted — they travel in plain text over HTTP.

FAQ

Add the following to your .htaccess or httpd.conf, pointing AuthUserFile at your generated .htpasswd file:
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Add the directives to your nginx.conf or the relevant server block:
location /admin {
    auth_basic "Restricted Area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}
Nginx supports both bcrypt and APR1-MD5.

bcrypt is strongly recommended for any Apache 2.4+ or Nginx setup. Use APR1-MD5 only when you need compatibility with Apache 2.2 or older. Avoid SHA-1 unless specifically required by a legacy system.

Simply append the generated line (username:hash) to the end of your existing file. Each line represents one user. Blank lines and lines starting with # are ignored.

Yes. All hashing happens entirely in your browser using JavaScript. No password data is transmitted to the server. That said, always use this tool on a secure HTTPS page and handle the generated file carefully.
ツールくん

Side Note — Why Basic Auth survives despite its age

HTTP Basic Authentication was defined in 1999 by RFC 2617 (later updated to RFC 7617). The mechanism is simple: concatenate username and password with :, Base64-encode the result, and send it in the Authorization header.

Its simplicity is exactly why it's still widely used. It's a go-to for staging environments, internal tools, or as a first line of defense combined with IP allowlisting. Two or three config lines are all you need — no extra middleware or database required.

The caveats are real, though: no logout mechanism (the session persists until the browser is closed), no built-in password expiry, and no multi-factor authentication. For production services with genuine security requirements, consider OAuth 2.0 or OIDC instead.

More tools in this category