Password protection for your website –
create a .htpasswd in 2 minutes

A plain text file with one line per user, following the pattern username:passwordhash. The Apache web server (and nginx too) compares submitted credentials against this file once a .htaccess activates the protection. The password itself never appears in plain text – only its hash is stored, a kind of cryptographic fingerprint.

No, at no point. This website password generator computes everything in your browser – there simply is no server-side code that could receive input. You can verify it yourself: open the network tab of your dev tools (F12), or just switch off Wi-Fi. The generator keeps working. Close the page and everything is gone; nothing is stored, not even settings. By the way: the site's anonymous visitor counting (see privacy policy) is entirely separate – it works without cookies by default, recognition cookies are only set with your consent, and neither has anything to do with your input in the generator.

On load, the tool recomputes a set of built-in test vectors – known passwords whose correct bcrypt, MD5 (APR1) and SHA-1 hashes were generated in advance with the server world's reference implementations (including OpenSSL). The green check mark only appears if every result matches bit for bit. At a glance, you can see that the cryptography works correctly in your specific browser and hasn't been corrupted by an exotic browser, an old device or a partially loaded page. If the test fails, the page says so openly – in that case, don't generate hashes; reload the page first.

Short answer: bcrypt. It's salted, deliberately compute-intensive and has been under scrutiny for over 25 years. Apache supports it since version 2.4 (released 2012) – a non-issue with practically every current host. Only fall back to APR1-MD5 if a genuinely old system is involved, and then please with a long random password. The full rating of every scheme is in the table above.

The single most common stumbling block. Apache needs the path in the server's file system (say /var/www/vhosts/example.com/.htpasswd), not the web address. Fastest route: the PHP one-liner from the builder – put <?php echo __DIR__; ?> in a file, open it, read the path, delete the file. Many hosting panels also show the path under keywords like "directory protection" or "web space path".

The .htaccess goes into exactly the directory you want to protect – it automatically covers all subdirectories as well. The .htpasswd is best stored outside the publicly reachable web folder, one level above httpdocs, htdocs or public_html. If your host doesn't allow that, no drama: by default, Apache blocks direct access to any file starting with .ht anyway.

Almost always one of three classics: a typo in the .htaccess, a wrong AuthUserFile path, or a directive your host doesn't permit. First aid: rename the .htaccess via FTP (e.g. to htaccess.txt) – if the site comes back, the file is definitely the culprit. Then double-check the path, regenerate the file with the builder and test step by step. Your host's error log usually names the cause outright.

Then the server is most likely ignoring your .htaccess entirely. On your own server/VPS, the vhost must have AllowOverride AuthConfig (or All) – the default is often None. On shared hosting, .htaccess support is almost always active; check instead whether the file is really called .htaccess (with the dot, no extension) and sits in the right directory. Some FTP clients hide dot files by default, by the way.

Yes, with two differences: nginx doesn't read .htaccess files – the protection belongs directly in the server configuration (auth_basic and auth_basic_user_file; the ready-made lines are in the builder's nginx tab). And which hash schemes work depends on the system's crypt library. Current Linux distributions accept bcrypt hashes in the $2y$ format without complaint.

Simply create another user here and append the new line to the end of your existing .htpasswd – exactly one line per user, order doesn't matter. Or rebuild the whole file in the generator: entries stay in the preview until you close the page. To remove a user, just delete their line.

The mechanism itself is simple: the browser sends username and password with every request – merely Base64-encoded, which is not encryption. Without HTTPS, anyone listening in could grab the credentials in plain text. Hence the clear rule: use directory protection only together with HTTPS (free at almost every host these days thanks to Let's Encrypt). With that in place, Basic Auth is a perfectly solid, battle-tested shield for staging environments, internal areas and client previews.

The password cannot be recovered from the hash – that's the whole point. Fortunately the fix is unspectacular: generate a new password here, replace the affected line in the .htpasswd with the new one, done. No data is lost; only the credentials change.

On principle. crypt(3) truncates passwords after 8 characters without telling you – the rest of your nice long password does nothing, and such a hash is cracked in minutes. Plain text, in turn, doesn't even work on Linux servers and would be a total loss if the file ever leaked. A generator that promises security shouldn't offer such traps – not even "for special cases".

For staging sites, admin areas and downloads for a limited circle: yes – combined with HTTPS and strong passwords, this has been established practice for decades. For highly sensitive data (medical records, financial data and the like), Basic Auth should be just one of several layers, e.g. on top of an application login. And one point that's easily forgotten: the protection only applies via the web server. Anyone with FTP access to the directory can still read the files.