We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
We use cookies.This website uses essential cookies to operate core features. With your consent, we also use analytics cookies to understand traffic and improve the service. For more details, see our .
Was this tool helpful to use?
Your feedback helps us make it better
Generate user authentication password files for Apache and other servers. Supports multiple encryption algorithms including BCrypt, MD5, and SHA-1.
Enter username and password to generate
Overview
Understand what the tool solves, how it works, and the boundaries of its data.
An .htpasswd file stores credentials for HTTP Basic authentication, usually as one username:password-record line per account. This generator takes one username and password and returns one line, which you can copy or download as a text file. It does not assemble multiple users into a file.
The username cannot contain a colon because the colon separates the two fields. The output is a password record, not an encrypted version that can be decrypted to recover the original password.
Bcrypt is the default. It produces an Apache-style $2y$ record using cost 10 and a fresh cryptographically random salt. The salt makes records for the same password differ, while the server checks a login against the stored record. The other option produces Apache's {SHA} form: a Base64-encoded SHA-1 digest. Apache identifies SHA-1 as an insecure, unsalted format, so reserve it for an existing system that specifically requires it. The two choices are the only formats offered here; there is no APR1, plain-text, or bulk mode.
Apache's documentation describes these record formats, but support can depend on the server and its configuration. Confirm that the target server accepts the chosen format before relying on the line. See the Apache password format documentation and its htpasswd guidance.
Guide
Follow the workflow and verify inputs and outputs with practical examples.
Use a username without colons or line breaks. Passwords cannot contain line breaks or NUL characters, and the password must be no more than 72 bytes when encoded as UTF-8. The field displays its contents as text, so avoid entering a live credential where other people can see the screen.
Keep bcrypt selected for the default salted format. Choose SHA-1 only when maintaining a legacy setup that explicitly requires it.
Once both fields pass validation, the result appears as one colon-separated line. Copy it or download the one-line .htpasswd text file. For another account, make a separate line and place each account on its own line in the file.
Before using the record for access control, test a temporary account against the actual server and authentication configuration. Server implementations and supported formats can differ.
Use cases
See how the tool fits into real work and everyday tasks.
A developer setting up a private preview can create one bcrypt record, then add it to the server's password file and verify the login with a test account.
An administrator whose existing service requires Apache's SHA-1 record format can select the compatibility option, then verify that requirement with the server configuration before use.
Q&A
Find concise answers to common questions and confusing cases.
Bcrypt uses a random salt, included in the record. Different lines can still validate the same password when the server supports the format.
The supported bcrypt path has a 72-byte input limit. The check counts encoded bytes, not displayed characters, so some non-ASCII characters use more than one byte. Shorten the password without accidentally changing the credential you intend to set.
It is intended only for legacy compatibility. Apache describes SHA-1 records as unsalted and insecure by current standards; use bcrypt when the destination supports it.
No. The record format is separate from the login exchange. HTTP Basic encodes the username and password with Base64, which is not encryption; use HTTPS/TLS. The IETF specification for Basic authentication explains this transport requirement.
Notes
Review scope, result limitations, and important precautions before use.
Do not treat a generated record as proof that a server configuration is secure or compatible. Test the chosen format on the destination system. Apache advises keeping password files outside the web server's directly accessible URL space so a browser cannot fetch them. HTTP Basic credentials also need HTTPS/TLS in transit; Base64 is an encoding, not encryption.
The password input is displayed as plain text while you type. Do not use a shared or visible screen for a real secret. SHA-1 is included only for backward compatibility and should not be selected for a new password file when bcrypt is supported.
Related
Discover related tools, collections, and available API capabilities.