Generate an .htpasswd File Line — Free Apache Auth Generator

Every time you need to lock down a directory on your Apache HTTP Server, the htpasswd file generator above gives you ready-to-paste credential entries in seconds — no terminal required. Whether you are protecting a staging environment, an admin panel, or any other restricted area on your server, the credential format you choose determines how well those entries resist real-world attacks. Understanding what goes inside your .htpasswd file, which algorithms are safe, and how to wire everything into Apache will help you make the right call for your setup.

What Is an Htpasswd File Generator and How Does the .htpasswd File Work?

The htpasswd utility is the canonical tool for managing access records that back HTTP basic authentication on Apache and compatible servers. At its core, the credential store is a simple flat-file — a plain text file — where each line holds a username and a hashed passphrase separated by a colon character. When a browser requests a restricted directory, the server reads this file, compares the submitted details against the stored password hash, and either grants or denies access. Because the file itself has no database overhead, it is ideal for lightweight protection on shared server environments, small intranets, and development servers. Using an htpasswd file generator lets you store passwords quickly without needing local command-line access — making it easier to protect a folder on any platform.

The file is typically named .htpasswd — note the leading dot, which makes it a hidden file (a dot file) on Unix-like systems such as Linux and macOS. It is also sometimes called a passwd file, an auth file, or simply a user file. The canonical name .htpasswd is a convention, not a requirement — the AuthUserFile directive in your .htaccess file tells the server where the actual passwdfile lives.

How Basic Authentication Uses the .htpasswd File

Basic authentication is an HTTP security framework defined in the HTTP specification. When a browser sends a request for a URI within a protection space, the origin server responds with a 401 Unauthorized status code and a WWW-Authenticate header containing a realm value. The browser then displays a login dialog, collects the login details, encodes the user-id and passphrase pair as a Base64 string, and resends the request with an Authorization header. If a proxy sits in the middle, the flow uses a 407 Proxy Authentication Required status and a Proxy-Authenticate header instead — this is proxy authorization.

The login scheme is identified by the case-insensitive token Basic in the auth-scheme field. The realm directive defines the protection space — it groups resources on the server so a single set of login details can cover multiple paths without repeated challenges. A user wishing to gain access to a restricted directory must supply the correct username and passphrase; any mismatch returns a new 401 challenge. The authentication framework is extensible, but Basic is still the most widely deployed scheme for simple directory security, especially when combined with TLS/SSL.

On the server side, Apache's mod_authn_file module reads the passwdfile, locates the line matching the submitted username, and runs credential checking by re-hashing the supplied passphrase with the same algorithm and salt string. If the output matches the stored record, the user is granted access. This server-side comparison is why the choice of hash algorithm matters so much — a weak algorithm makes brute-force and word-list attacks far more feasible.

Supported Algorithms and Formats for Htpasswd Entries

Apache recognizes five encoding schemes for storing hashed passphrases in its credential files. Each uses a different format, and the prefix embedded in the entry tells Apache which verification routine to use. Here is a breakdown of every encoding type:

bcrypt — $2y$cost$...

The bcrypt scheme is the strongest option currently available. It applies a cost factor (number of iterations) that makes each check intentionally slow, dramatically increasing the computing time required for brute-force attacks. This is the recommendation for Apache 2.4+. Internally it uses the Blowfish-based algorithm and generates a unique random value per entry, providing strong secure access control for protected areas.

APR MD5 — $apr1$salt$hash

This is the MD5 modified for Apache format — also called APR1 or apr md5. It applies an iterated digest (1,000 iterations) of combinations of a random 32-bit value and the passphrase. The result is a 128-bit output expressed as 32 hexadecimal digits. MD5 was designed by Professor Ronald Rivest of MIT and is part of a family of message digest algorithms; the Apache-specific variant (md5 modified) adds iteration and mixing to resist word-list attacks. The prefix $apr1$ distinguishes it from standard digest values. This format is broadly compatible — it works on any platform including the linux platform, macOS, and Windows.

SHA-1 — {SHA}base64digest

SHA-1 produces a 160-bit digest from the passphrase, then stores it as a base64 encoded string prefixed with {SHA}. The sha1 format is considered a legacy option. Critically, SHA-1 uses no salting: for any given passphrase, there is only one possible digest — making it far easier to attack with precomputed rainbow tables. This approach is therefore insecure for new deployments. Also sometimes written as apr sha or alg apsha in source constants. The SHA hash family was designed by the NSA and published as a NIST standard (a Federal Information Processing Standard). SHA-1 forms part of TLS, SSL, PGP, SSH, S/MIME IPsec, and other protocols — but its use in passphrase-storage is now deprecated.

SHA-256 / SHA-512 — {SHA256}base64digest / {SHA512}base64digest

These sha-2 algorithms (part of the sha-2 based hashes family) are supported in newer Apache builds via the apr-util library. SHA-256 produces a 256-bit output; SHA-512 produces 512 bits. Like SHA-1, they remain free of added entropy by default in the basic format, limiting their advantage over raw SHA-1. The sha-crypt variant (used in Linux shadow entries) does add mixing but is separate from the built-in formats.

crypt — traditional format

The crypt method (also called unix crypt, or alg crypt in source) uses the crypt function from the C standard library — specifically the crypt() routine. It applies a 32-bit salt (only 12 bits used) and cuts the passphrase to 8 characters. This approach is available on POSIX-compatible systems but may not function on a Windows platform. Passphrases longer than 8 characters are silently shortened, making it unsuitable for strong passphrase policies. The implementation uses added entropy to deter word-list attacks, but its short key space makes it weak by modern standards.

Plain text — unencrypted

Plain text stores the passphrase as-is — completely unobscured. This is supported only on Windows, BeOS, and Netware (alg plain). In a credential file, the passphrase is clearly visible to anyone who can read the file. This format must never be used in production. It is flagged as insecure throughout Apache documentation.

A sample .htpasswd file showing three entries with APR-MD5 hashes looks like this:

user1:$apr1$clme56rh$7kbO8h94VA5UWBNpdayu80
user2:$apr1$l76zf4jy$M7064lZwDjJjGigJ48fqP/
user3:$apr1$f2dmapgz$C.8mBkD1DoUiBVJGaCfJM0

Each line is a login record: the user name, a colon, and the hashed passphrase. The file may contain a mixture of different encoding types — some entries may use bcrypt while others use crypt() or MD5. Empty lines and annotation lines beginning with a hash character are ignored. Usernames are limited to 255 characters and must not contain a colon. The passphrase length limit varies by algorithm — the crypt routine silently cuts at 8 characters, while bcrypt and MD5 support longer inputs.

Protecting a Directory with Apache Using Your Htpasswd File

Once your online htpasswd generator has produced a valid .htpasswd file, the next step is to configure Apache to enforce protection on the target directory. This involves two files: the credential store itself and a .htaccess file placed in the directory you want to protect. The configuration settings in the htaccess file tell Apache which login scheme to use, what realm to display in the browser's dialog, and where to find the passwdfile.

A minimal .htaccess configuration for htaccess authentication looks like this:

AuthType Basic
AuthName "My Restricted Area"
AuthUserFile /var/www/.htpasswd
Require valid-user

• AuthType Basic — activates the basic authentication scheme. This is the authtype basic directive.
• AuthName — sets the realm value displayed in the browser login prompt. This is the authname setting.
• AuthUserFile — the absolute path to your credential file. This is the authuserfile directive.
• Require valid-user — instructs Apache to grant access to any user listed in the passwdfile who provides the correct passphrase. This is the require valid-user directive.

The .htaccess rules apply to the directory they are placed in and all sub-directories below it — that is, the entire URI space rooted at that path. The authuserfile path must be an absolute path on the storage layer. Critically, the credential store must not be placed inside the web root in a location that is directly fetchable by a browser; store it above the document root or in a directory without public read access. This protects your login data from being downloaded as a text file by an attacker.

To protect directory contents on a server where you cannot place a .htaccess file, you can configure the same settings directly in your httpd.conf or a <Directory> block — a server configuration approach that is more efficient because Apache does not need to traverse the storage layer reading per-directory files on every request. Always reload or restart the httpd server after making changes to the server config to apply new access control rules.

Apache Htpasswd Error Messages and Exit Status Codes

The native htpasswd command returns an exit status to indicate the outcome of each operation:

• 0 — Success: the operation completed and the file was rewritten or the login record was written to stdout.
• 1 — Failure: a file access permission problem (fileperm), a file open / file close error, an inability to read the file, or a failure to create a staging copy in the temp directory.
• 2 — Failure: a terminal syntax problem — a usage message is issued. This covers missing arguments or conflicting flags (e.g., using -c and -D together, or -c and -n together).
• 3 — Failure: entry mismatch (PWMISMATCH) — the re-type prompt did not match the new passphrase.
• 4 — Failure: operation interrupted (e.g., Ctrl+C).
• 5 — Failure: buffer overflow — the username, filename, or computed value is too long.
• 6 — Failure: username too long or passphrase too long (exceeds MAX_STRING_LEN); or the username contains a disallowed character (BADUSER).
• 7 — Failure: the file is not a valid credential file — possibly a corrupted file or a file where lines contain no colon separator.

Common error messages you may encounter include:

• cannot open file passwdfile for read access — the file exists but Apache lacks read access; check file permissions.
• cannot create file passwdfile — the directory lacks write access for the Apache process.
• cannot modify file passwdfile; use -c to create it — you omitted -c when the file does not yet exist.
• username contains illegal characters: $c — the username includes disallowed characters (such as a colon).
• password too long / password too short — the supplied passphrase falls outside the algorithm's accepted length range.
• unable to create temporary file — the system's temp directory is not writable; the tool creates a staging copy before doing an atomic rename.
• password verification error (PWMISMATCH) — the two interactive entries did not match.
• unable to update file passwdfile — a storage-level error prevented the final rename from the temp location.
• file is not a valid htpasswd file — the credential file check failed, possibly because annotation lines or corrupted entries lack the colon separator.

Security Info and Common Restrictions on Username and Password

Apache imposes several restrictions on the content of credential files that this htpasswd file generator handles for you automatically:

• Username length: usernames are limited to 255 characters. The MAX_STRING_LEN constant governs this in Apache source. A username too long error is raised if this is exceeded.
• Colon restriction: usernames must not contain a colon (:) because it serves as the field delimiter in every login record.
• Passphrase length for crypt: the crypt() routine silently cuts passphrases to 8 characters. Any characters beyond the eighth are ignored during both storage and credential checking.
• File size: there is no hard limit on the number of entries, but very large credential files impact performance because Apache performs a linear scan on each request. For large user bases, consider switching to a DBM-backed store via dbmmanage or htdbm, or use LDAP-backed login handling.
• Disallowed characters: beyond the colon, certain control characters are rejected. The BADUSER error code flags usernames containing these disallowed characters.
• Setuid executable: on some POSIX systems, htpasswd may be installed as a setuid executable to allow non-root users to refresh their own entries safely. Verify file permissions on the passwdfile so that only the server process has read access and only the admin account has write access.

Htpasswd Resources, Source Code, and Related Apache Tools

The htpasswd utility ships as part of the standard Apache distribution and is documented in the official Apache manual — the htpasswd manual page covers every flag, restriction, and exit status code. Related utilities in the Apache toolchain include:

• htdigest — the htdigest creator for managing digest authentication credential files.
• dbmmanage — manages user entries in a DBM-backed file, suitable for very large user bases.
• htdbm — a newer replacement for dbmmanage with a broader feature set.
• openssl passwd — the OpenSSL CLI command for generating hashed passphrase values including APR MD5 and sha-crypt variants; part of the TLS/SSL toolkit (tls ssl).
• mod_authn_file — the Apache module that reads credential files and performs user login checking during request processing. It is the server-side engine behind everything this htpasswd tool produces.

Htpasswd Source Code — Key Constants

The htpasswd source code (available in the Apache distribution's support/ directory and on the Apache HTTPD source repository) defines several constants that map directly to the available algorithms and operational modes described above. Reviewing these helps you understand what the generator and the CLI tool are doing under the hood:

• ALG_APMD5 — APR MD5 (md5 modified for apache, apr md5)
• ALG_APSHA — SHA-1 (apr sha, sha1 base64)
• ALG_PLAIN — plain text (alg plain, Windows/Netware only)
• ALG_CRYPT — crypt (alg crypt, POSIX platforms only)
• APHTP_NEWFILE — flag indicating the create-file (-c) mode was requested
• APHTP_NOFILE — flag indicating stdout-only mode (-n, no file written)
• APHTP_NONINTERACTIVE — non-interactive mode (-b), passphrase supplied via terminal or stdin
• APHTP_DELUSER — remove user mode (-D)
• BADUSER — error code for usernames containing disallowed characters
• FILEPERM — error code for file permissions problems on the passwdfile
• PWMISMATCH — error code for entry mismatch during interactive input

Internally, the tool creates a staging copy in the system's temp directory, copies all existing entries into it (skipping or replacing the target username), then does an atomic rename to the final destination — a safe strategy that prevents corruption if the process is interrupted. If APHTP_NEWFILE is set, it skips the copy step and just creates a fresh file. The process validates that the target passwdfile is a valid credential file by checking that every non-empty, non-annotation line contains a colon separator. Lines starting with a hash character are treated as annotations and preserved.

Related Apache and Web Server Authentication Tools

Beyond the core htpasswd workflow, several related utilities and resources expand your server login capabilities. The tools listed here are useful companions for anyone managing credential files on Apache:

• Apache mod_authn_file documentation — explains all AuthType, AuthName, AuthUserFile, and Require configuration settings in detail. Essential reading for configuring access control tasks.
• PHP htpasswd libraries — php htpasswd packages like hautelook/phpass let you encode passphrases server-side in PHP using the same APR MD5 and bcrypt formats, enabling dynamic user management without shell access.
• OpenSSL passwd — a terminal tool for generating hashed passphrase strings including APR1 and sha-crypt variants; often available on systems where htpasswd is not installed. Part of the broader cryptography toolkit covering TLS, SSL, PGP SSH, and S/MIME IPsec use cases.
• htaccess generator — a companion tool to produce the full .htaccess file configuration block with AuthType, AuthName, AuthUserFile, and Require valid-user already filled in. Pairs with this tool to give you a complete htaccess login setup.
• Base64 image converter and other encoding tools — while not directly related to htpasswd, these utilities are part of the same family of web developer tools that cover encoding, transformation, and data-processing needs.
• LDAP / LDIF tools — for enterprises needing centralized identity verification across multiple server instances, LDAP-backed login replaces flat-file htpasswd with a scalable directory store compatible with modern LDAP directories.

Whether you use this htpasswd file generator as a quick one-off tool or as part of a repeatable deployment process, understanding the full chain — from algorithm selection, through htaccess authentication configuration, to hardening your setup — ensures that your protected resources remain genuinely secure. Always prefer bcrypt, always use HTTPS, keep your credential files outside the web root, audit your entries regularly, and use a passphrase manager to generate truly random, high-entropy secrets for every username in your auth file.