Password Generator

This tool generates random passwords using the browser’s cryptographically secure random number generator (crypto.getRandomValues); nothing about the generated password leaves your machine.

What makes a password strong

Two properties:

1. Entropy. Bits of randomness. A 12-character password from a 26-character alphabet has ~56 bits; from a 95-character alphabet, ~79 bits. More bits = more guesses an attacker has to try.
2. Source. The randomness must come from a CSPRNG. Math.random() is not. Browser crypto.getRandomValues() is.

The tool above uses crypto.getRandomValues(). Always.

How long is long enough

The bit count required depends on the threat model:

For comparison: a 16-character random alphanumeric password is ~95 bits. That resists offline dictionary attacks at modern hardware speeds for a long time.

Length vs character classes

The legacy advice “use uppercase + lowercase + digits + symbols” is mostly wrong. The math:

• An 8-char password from a 26-char alphabet: 26⁸ ≈ 2 × 10¹¹ ≈ 38 bits.
• A 12-char password from a 26-char alphabet: 26¹² ≈ 9 × 10¹⁶ ≈ 56 bits.
• An 8-char password from a 95-char alphabet: 95⁸ ≈ 7 × 10¹⁵ ≈ 53 bits.

The 12-char all-lowercase password has more entropy than the 8-char all-character-class password.

In practice, a 16-character random password from any reasonable alphabet is fine. The character-class rules exist because they make humans pick less-bad passwords; for random passwords, they don’t help much.

Excluded characters

When passwords need to be readable or typed:

• Visually ambiguous chars: 0 (zero) vs O (capital o) vs o. 1 vs l vs I. Generators sometimes exclude these for read-aloud-and-type scenarios.
• Symbols that don’t paste cleanly: angle brackets, ampersands, quotes — fine in most contexts but break in some legacy systems.
• Special characters in shells: $, `, \, ', " — fine in passwords but cause parsing issues if the password is ever embedded in a shell command or unquoted environment variable.

The tool above has no exclusion options: its symbol set is !@#$%^&*()_+-=[]{}|;:,.<>?. If a system rejects those, use the “no symbols” option — at 16 characters it’s still about 95 bits.

Passphrases

The alternative to a long random string: a sequence of random words from a list. The diceware approach uses 7,776-word lists; ~13 bits per word.

Random alphanumeric (16 chars): X7r9MqpVnHzKw2bA
Diceware passphrase (5 words):   correct-horse-battery-staple-quirk

The random string is about 95 bits; five diceware words are about 65. The passphrase is much easier to type and memorize, and adding a sixth word (≈78 bits) closes most of the gap. For a master password you have to memorize, passphrases beat character salads.

The tool above’s Memorable option builds a passphrase of six words from the EFF short word list (1,296 words, ≈10.3 bits each), about 62 bits in total — strong enough for accounts protected by a slow password hash. For a password-manager master password, use more words or the diceware long list.

What the server should do

The user-side concern: pick a strong password and store it in a password manager. The server-side concern (if you operate one):

• Use a slow password hash. Argon2, bcrypt, scrypt. Not SHA-256, not MD5. See SHA-256 for why fast hashes are wrong for passwords.
• Salt per-user. Modern password hashers do this for you.
• Allow long passwords. Some legacy systems truncate at 8, 16, or 32 characters. A password manager picks 128-character passwords; if the server silently truncates, security degrades without the user noticing.
• Allow all reasonable characters. Any printable Unicode should be valid. Banning special characters is a 1990s habit that does nothing useful.
• Don’t enforce composition rules. “Must include 1 uppercase, 1 number, 1 symbol” prevents users from picking some good passwords, doesn’t prevent them from picking bad ones, and is a usability tax. NIST removed this guidance in 2017.

Password vs API key vs token

Different things, different rules:

Use the right tool. Password generators are for things humans memorize or save in password managers. For programmatic credentials, see API key generator and UUID generator.

Common pitfalls

• Generating with Math.random(). Predictable. Never use for passwords.
• Reusing passwords. A breach at any site you’ve reused at compromises you everywhere. Use a password manager.
• Storing passwords in plain text or with reversible encryption. Hash with Argon2/bcrypt/scrypt. Plain SHA-256 is not enough.
• Banning paste in password fields. Forces users to type long passwords by hand, encouraging shorter passwords. Browsers and password managers depend on paste; banning it is anti-security.
• Sending the password in URLs or email. Either is logged and observable. Use HTTPS POST with proper authentication channels.
• Custom “encryption” of passwords. Not your own crypto. Use libraries (libsodium, browser SubtleCrypto, established server-side hash libraries).

For checking the strength of a password you’ve chosen, see password strength. For non-password tokens, API key generator.