Password Generator

What "strong" actually means

Password strength is measured in bits of entropy — log2 of the number of possible passwords your generation scheme could have produced. A 20-character password drawn from 95 printable characters has ~131 bits of entropy. A "P@ssw0rd!" might be 8 characters but the entropy is far lower because attackers know to try common substitutions.

The intuition: length crushes complexity. A 20-character password with only lowercase letters (94 bits) is far stronger than an 8-character one with all symbols (52 bits), and easier to remember.

Modern guidance (NIST SP 800-63B) reflects this:

• 12+ characters minimum, 16+ recommended
• No mandatory periodic rotation (it makes passwords weaker, not stronger)
• No "must include uppercase + symbol" rules (drives users to predictable patterns)
• Reject passwords found in known-leak databases

How this tool generates

We use crypto.getRandomValues, the browser's cryptographically secure random number generator. Every character is picked uniformly at random from your chosen charset. There's no seed, no Math.random (which is NOT secure), no predictability.

The character pool you select directly determines the entropy:

| Charset | Pool size | Bits per char | |---|---|---| | lowercase only | 26 | 4.7 | | + uppercase | 52 | 5.7 | | + digits | 62 | 5.95 | | + symbols | ~94 | 6.55 |

The estimate at the top of the generator multiplies length × bits-per-char and converts to a crack-time estimate, assuming an offline attacker with a high-end GPU farm at 10 billion guesses/second. That's deliberately pessimistic — most real attackers can't sustain that rate.

The exclude-ambiguous toggle

Some characters look alike at small font sizes: 0 and O, l and 1 and I, the backtick and apostrophe. When excluded, you give up ~6% of entropy in exchange for being able to dictate the password over the phone or read it from a printout. Worth it for one-time-use scenarios; skip when generating for password-manager-only use.

The single rule everyone breaks: don't store passwords as SHA-256

If your application accepts user passwords and stores them, you have one job: don't hash them with a fast algorithm. SHA-256, SHA-1, MD5 — all forbidden. The right answer is a slow, memory-hard, salted hash:

• Argon2id — current state of the art
• bcrypt — older but still acceptable
• scrypt — fine for some use cases

These are intentionally ~100ms per hash, which is invisible to a user logging in but ruinous for an attacker trying billions of guesses against a stolen database. Use a library, don't roll your own.

Where to actually store passwords

Not in your head, not in a spreadsheet, not in a text file. Use a password manager:

• 1Password (paid, polished, family plans)
• Bitwarden (open source, free tier covers most users)
• Apple Passwords / iCloud Keychain (iOS/macOS users)
• KeePassXC (offline, self-hosted)

The manager generates and stores passwords for you so you only need to remember one master password. Make that master password 20+ characters of memorable nonsense (a passphrase like correct horse battery staple works well — it's ~44 bits but you can remember it).

Use cases in this tool

• Generating service credentials you'll save in a password manager
• Generating random API keys, webhook secrets, JWT signing keys
• Generating one-off temporary passwords to share over a secure channel
• Generating database seeds or test fixtures

Privacy

Generation is entirely client-side. The page never sends your generated password anywhere. Open the Network tab — silence while you click Generate. The browser's CSPRNG is the source of entropy; we never see the output.

Related tools

• Hash Generator — see what SHA-256 of your password looks like (and learn why that's not how passwords should be stored).
• UUID Generator — when you need a unique structured ID, not a password.

How long should my password be?

12+ characters minimum, 16+ recommended for anything important, 20+ for master passwords. Length matters more than complexity — a 20-char lowercase password is stronger than an 8-char mix-of-symbols one.

Are passphrases (correct horse battery staple) better than random strings?

For memorability, yes. Four random English words give ~44 bits of entropy, enough for everyday account passwords (though we'd lean to five or six words for higher-stakes accounts). Random strings hit higher entropy per character but only matter when you're not memorizing them — for password-manager-stored credentials, take the random string.

Why does ambiguous-char exclusion lose entropy?

It removes ~6% of the character pool, which slightly reduces bits-per-character. You get back the ability to read the password out loud or off a printout without ambiguity. Worth the trade for one-time-use or written passwords; skip for password-manager-only use.

Is the randomness here secure?

Yes. We use crypto.getRandomValues, the browser's CSPRNG, which is suitable for generating cryptographic keys. We do NOT use Math.random, which is predictable and insecure.

Is my generated password sent to your server?

No. The page does all generation locally. Open DevTools Network and click Generate — you'll see zero requests.

Should I rotate my passwords periodically?

NIST no longer recommends mandatory periodic rotation. It forces users into predictable patterns (Spring2024! → Summer2024!). Rotate when you have reason to believe a password is compromised (breach notification, suspicious activity); otherwise leave strong unique passwords in place.

Why is "P@ssw0rd!" weak even though it has all four char types?

Because attackers know to try common-word + common-substitution patterns first. Real entropy comes from being one of many equally likely possibilities — P@ssw0rd! is one of maybe a few thousand "obvious clever variants", not one of 95^9 = 6e17 random possibilities.