Password Generator & bcrypt
Cryptographically random passwords with an entropy readout, plus bcrypt hashing and verification.
Runs entirely in your browser — nothing you paste is uploaded.
About Password Generator & bcrypt
Two related jobs. The generator produces passwords from `crypto.getRandomValues` — the platform's cryptographically secure source — with toggles for lowercase, uppercase, digits and symbols, and a length slider. Never `Math.random`, which is a predictable pseudo-random generator that an attacker who sees a few outputs can reconstruct.
The entropy readout is the number that matters and the one most generators omit. Entropy in bits is `length × log2(charset size)`: a 16-character password from the full 94-character printable set carries about 104 bits, while an 8-character lowercase one carries 37 — which is a few hours of offline cracking. Below 60 bits is weak, 80 is reasonable, 100+ is comfortable for anything long-lived.
The bcrypt half hashes a password at a cost factor between 4 and 12, and verifies a password against an existing hash. Cost is a work factor: each increment doubles the time. Cost 12 takes roughly a quarter of a second in a browser, which is the point — a function slow enough to make a billion-guess-per-second GPU attack impractical. Costs above 12 are refused here with an explanation rather than silently attempted, because they take long enough in JavaScript to look like a hang.
bcrypt salts automatically — the salt is embedded in the output string, which is why hashing the same password twice gives different results and why both verify. It also silently truncates input at 72 bytes, so a very long passphrase is not as strong as its length suggests.
Frequently asked
›How long should a password be?
Long enough to clear about 80 bits of entropy. With a full mixed charset that's around 13 characters; with lowercase letters only it's 18. Length buys more than complexity does — adding a character multiplies the search space by the charset size.
›What bcrypt cost factor should I use?
10 to 12 on a server in 2026, tuned so hashing takes 100–250ms on your hardware. Higher is stronger but becomes a denial-of-service surface on your own login endpoint. Re-hash at a higher cost on successful login as hardware improves.
›Why does the same password produce a different bcrypt hash each time?
Because bcrypt generates a random salt per hash and stores it inside the output string. That's what defeats rainbow tables. Verification reads the salt back out of the stored hash, so both hashes verify the same password.
›bcrypt, scrypt or Argon2?
Argon2id is the current recommendation — it resists GPU and side-channel attacks better. bcrypt remains perfectly acceptable and is available everywhere, which is why it's what's implemented here. scrypt sits between them. Any of the three beats a plain SHA hash by an enormous margin.
›Is the generated password sent anywhere?
No. Generation, hashing and verification all happen in your browser, and the password never appears in the URL or in browser history.