Htpasswd Generator — Apache basic auth lines, generated locally

An htpasswd generator produces the single line Apache needs to authenticate a user with HTTP basic authentication: a username, a colon, and a hashed password. Normally that line comes from the htpasswd command line utility, which is fine when you have shell access to the server and inconvenient when you do not.

The important thing about generating one in a browser is where the hashing happens. This page computes the hash locally in JavaScript. Your password is never transmitted, never logged, and never seen by any server, including ours. Arb Digital built it that way because the alternative — pasting a password into a form that posts it somewhere for hashing — hands your credential to a third party before you have even used it.

What This Htpasswd Generator Does

Enter a username and password, and the tool produces a complete htpasswd line using the APR1 algorithm: MD5 applied over 1000 iterations with an eight-character salt, in the specific arrangement Apache's portable format defines. The output looks like user:$apr1$saltsalt$hashvalue and can be appended directly to a password file.

A SHA-1 option is included for legacy systems that require the older {SHA} format. It is unsalted, single-pass, and materially weaker — it is offered because some appliances and older configurations still accept nothing else, not because it is a reasonable default. The results panel shows the salt in use, the number of hash rounds, your password length, and an entropy estimate derived from the character sets present.

The tool also emits the matching Apache directives, because a password file with no configuration pointing at it does nothing.

How to Use It

1. Enter the username. Avoid colons, which act as the field separator in the file format.
2. Enter the password. It is displayed in plain text so you can check it before committing to a hash you cannot reverse.
3. Leave the salt blank unless you are reproducing a specific known hash. A fresh random salt per user is the correct default.
4. Copy the generated line and append it to your .htpasswd file. Each user gets one line.
5. Add the configuration block to your Apache config or .htaccess, pointing AuthUserFile at the absolute path of the password file.

The Formula / How It's Calculated

APR1 is a variant of the older MD5-crypt scheme, adapted by the Apache Portable Runtime. It begins by hashing the password, the literal string $apr1$, and the salt together. A second hash of the password, salt, and password again produces an intermediate value, which is folded into the first context one byte at a time for as many bytes as the password is long.

Then comes a deliberately awkward loop. The password length is walked bit by bit, appending either a null byte or the first character of the password depending on each bit. The result is hashed, and that hash is fed into a thousand further rounds in which the password, the salt, and the previous hash are combined in an order that changes according to whether the round number is odd, divisible by three, or divisible by seven.

The final sixteen bytes are re-ordered and encoded using a base-64 alphabet that starts with a dot and a slash rather than the standard one, producing the twenty-two character hash you see after the salt. All of that exists for one reason: to make each password guess expensive enough that testing a large dictionary takes meaningfully longer than a single MD5 would. The full algorithm is described in the Apache password formats documentation.

Be Clear-Eyed About What APR1 Protects Against

APR1 is not a modern password hash. MD5 is fast, and a thousand iterations is a small multiplier compared with what current hardware can attempt per second. Bcrypt, which Apache supports through the -B flag of the htpasswd utility, is designed to be slow in a tunable way and is the algorithm the Apache documentation now recommends.

Bcrypt cannot be computed reliably in a browser without pulling in an external library, which would defeat the point of a page that makes no network requests, so this tool implements APR1 correctly rather than implementing bcrypt approximately. The honest framing: APR1 is appropriate for gating a staging site, a development environment, or an internal dashboard behind a shared credential. It is not appropriate as the only protection on customer data, payment functions, or administrative access to a production system.

If your password file is stolen, the strength of your password matters far more than the strength of the algorithm. A long random passphrase remains impractical to crack even under a fast hash; a dictionary word does not survive any hash function at all.

Why Basic Auth Requires HTTPS Without Exception

HTTP basic authentication does not encrypt anything. It base64-encodes the username and password and sends them in a header on every single request. Base64 is an encoding, not a cipher — decoding it is a one-step operation with no key involved.

Over plain HTTP, that means the credential is readable by anything on the network path, and it is retransmitted with every image, stylesheet, and script the page loads. Over HTTPS the transport is encrypted and the exposure is limited to the endpoints. There is no configuration that makes basic auth safe over plain HTTP; the only correct answer is to require TLS on any path protected this way. The mechanism itself is defined in RFC 7617, which states the same constraint.

Where the Password File Belongs

The most common deployment mistake is putting .htpasswd inside the web root. If the file is reachable by URL, anyone can download every hash in it and start cracking offline at their own pace, with no rate limiting and no logging. Placing it above the document root removes that possibility entirely.

File permissions matter too: the file needs to be readable by the web server user and by nobody else. And because the leading dot only hides the file from a casual directory listing on Unix-like systems, it provides no protection whatsoever from a direct request. If you genuinely cannot place the file outside the web root, an explicit deny rule for files matching the name is the minimum mitigation, but relocating it is the real fix.

Salts, and Why Two Users With the Same Password Look Different

The salt is eight random characters stored in plain sight inside the hash string. Its job is not secrecy — it is to make identical passwords produce different hashes. Without a salt, two accounts sharing the password letmein would produce byte-identical hashes, which tells an attacker instantly that cracking one breaks both, and allows precomputed rainbow tables to be used against the whole file at once.

With a per-user salt, every password must be attacked individually and precomputation becomes useless. This is exactly why the SHA-1 option in this tool is weaker than its digest length suggests: {SHA} entries carry no salt, so identical passwords produce identical hashes across every user and every server using the format.

Managing More Than a Handful of Users

Basic auth has no password reset, no lockout after failed attempts, no session concept, no audit trail, and no way to revoke one person's access without editing a file. Every one of those is fine for three developers sharing a staging gate and unworkable for thirty people across two teams.

The signal that you have outgrown it is usually operational rather than technical: someone leaves and the shared password has to be rotated for everyone, or a person needs access to one path but not another. At that point the answer is an application-level login with per-user accounts, or an identity provider fronting the site, rather than a larger password file. Basic auth is a doorstop, and it works well as long as you remember that is what it is.

Common Mistakes to Avoid

• Storing the password file inside the web root. If it can be fetched by URL, every hash in it can be attacked offline.
• Using basic auth over plain HTTP. Credentials are only base64-encoded and are resent with every request on the page.
• Reusing one salt for every user. Identical passwords then produce identical hashes and precomputation becomes viable again.
• Overwriting the file when adding a user. Append the new line; the command line utility silently truncates without the right flag.
• Treating basic auth as real access control. There is no lockout, no audit trail, and no way to revoke one person without changing everyone's password.

Related Free Tools From Arb Digital

Create a strong credential first with the password generator, compute a plain digest with the hash generator, encode or decode a header value using Base64 encode and decode, inspect a bearer token with the JWT decoder, and write server rules with the htaccess redirect generator. The rest are in the free online tools hub.

Frequently Asked Questions

This tool generates password hashes for server configuration. It is not security advice — assess the sensitivity of what you are protecting and choose an authentication method that matches it.