Password Generator

Most password generators output a string and call it done — they don't tell you whether the output is actually strong, what makes it strong, or how it stacks up against common attack patterns. So you end up trusting it on faith.

This one shows the entropy in bits, the estimated time to crack at modern hash-cracking speeds (GPU-based, salted bcrypt baseline), and which character classes contribute to the strength. Adjust length and character classes — uppercase, lowercase, digits, symbols, ambiguous-character exclusion — and watch the entropy update. Generation uses the browser's crypto.getRandomValues, not Math.random, which matters because Math.random is predictable and not cryptographically suitable.

The character entropy model assumes a uniform random distribution, which it is. Real passwords humans pick are far weaker than entropy math suggests because human choices aren't uniform — that's a separate problem this tool sidesteps by generating, not advising.

The entropy math is mechanical: for a uniformly random selection from an alphabet of size N, each character contributes log2(N) bits. Lowercase only (26 chars) is 4.7 bits/char, lower+upper (52) is 5.7, alphanumeric (62) is 5.95, full ASCII printable (94) is 6.55, and a much larger Unicode set is meaningless because no system actually accepts arbitrary Unicode in passwords. A 16-character password from the 94-char alphabet is 16 × 6.55 ≈ 105 bits — well past any feasible brute force. The generator uses crypto.getRandomValues for the actual selection, which the browser sources from an OS-level CSPRNG; this matters because Math.random is predictable from a small number of outputs and unsuitable for any security purpose.

Worked example: a 20-character password with lowercase, uppercase, digits, and symbols. Effective alphabet ~94 chars, entropy ~131 bits. At a hash-cracking speed of 10 billion guesses per second (high-end GPU rig against fast unsalted hashes), 2^131 / 10^10 ≈ 10^29 seconds, or roughly 10^21 years. For Argon2id-hashed passwords, that GPU rig drops to a few thousand guesses per second, making the time astronomically larger. The lesson: 80+ bits is plenty for any modern hashing scheme; the failure is almost never that the password was too short, it's that the storage was too weak.

Where this calculator's number gets misleading: it assumes uniform random selection, which is true for what it generates. A password a human "made up" using "memorable" rules has dramatically less entropy than its character count suggests — common substitutions (a → @, e → 3) add maybe 2 bits total because attackers know the rules. Dictionary-based attacks reduce a "Tr0ub4dor!" type password to under 30 effective bits, regardless of how long it looks. Use the generator; don't trust your own pattern-making.

The practical edge case is sites that limit password length or character set. Some banks still cap passwords at 12 characters or forbid certain symbols, which is a reliable indicator that the site is storing passwords in a way that should make you nervous. The generator can adapt — restrict to allowed characters and pick a length the site accepts — but the underlying problem is the site, not the password. Use a password manager to generate per-site, accept that some sites give weaker effective security, and prefer 2FA wherever offered to compensate.