🔑 Random Password Generator
Character Types
Rules
Password Strength Is Just Arithmetic
A random password's strength is measured in bits of entropy: with a character pool of size N and length L, entropy = L × log₂N. Each character set you enable grows N (lowercase = 26, + uppercase = 52, + digits = 62, + symbols ≈ 86), and every extra character of length multiplies the search space by N again. That's why length beats complexity: going from 8 to 12 characters adds far more entropy than adding a symbol to an 8-character password ever could.
| Composition | Length | ≈ Entropy | Offline brute force @ 10 billion guesses/sec |
|---|---|---|---|
| Digits only | 8 | 27 bits | under a second |
| Lowercase only | 8 | 38 bits | ~21 seconds |
| Full charset | 8 | 52 bits | ~6 days |
| Full charset | 12 | 78 bits | ~960,000 years |
| Full charset | 16 | 105 bits | longer than the age of the universe |
The table assumes truly random characters. A human-invented password like Summer2024! looks like it belongs in the 11-character row, but crackers run dictionary-plus-rules attacks first (word + year + trailing symbol is rule #1), so its effective entropy is closer to 30 bits. That gap between apparent and real entropy is the entire reason to use a generator.
What NIST Actually Recommends (It's Not What Most Sites Enforce)
NIST's SP 800-63B Digital Identity Guidelines — the most-cited password standard in the industry — reversed several pieces of 2000s-era "security wisdom":
- No forced composition rules. Requiring "at least one uppercase, one digit, one symbol" pushes users toward predictable patterns like
Password1!. Length and a breach blocklist protect better. - No scheduled password expiry. Forced 90-day rotation produces
hunter2 → hunter3, not stronger secrets. Change passwords when there's evidence of compromise. - Check against known-breached passwords. Any candidate appearing in a leaked-password corpus (the kind Have I Been Pwned's Pwned Passwords API exposes) should be rejected outright.
- Allow paste and password managers. Blocking paste actively harms security by punishing exactly the users doing it right.
Many sites still enforce the legacy rules anyway. This generator's "ensure each selected type appears at least once" option exists for exactly those sites — it satisfies composition checkers while keeping the rest of the password uniformly random.
Random Strings vs Passphrases
The famous XKCD "correct horse battery staple" comic popularized diceware passphrases: four to six random words from a large wordlist. Which should you use?
- Random string (this tool): maximum entropy per character. The right choice for anything a password manager types for you — which should be nearly everything.
- Passphrase: ~13 bits per word from a 7,776-word diceware list, so five words ≈ 64 bits. Weaker per character but far easier to type and memorize — the right choice for the handful of secrets you must keep in your head: your password manager's master password, your computer login, full-disk encryption.
The trap is the middle ground: a "memorable" password you invented yourself is usually neither high-entropy nor actually memorable across 80 accounts. Pick one of the two disciplined options per use case.
Why Reuse Is the Real Killer: Credential Stuffing
Most account takeovers don't involve cracking anything. Attackers take username/password pairs from one site's breach and replay them against hundreds of other sites — credential stuffing — with automated tooling and success rates around 0.1–2%. At billions of leaked credentials, that's millions of compromised accounts, no brute force required.
The defense is structural, not clever: a different random password for every site, so one breach compromises exactly one account. Generate here, store in a manager (Bitwarden, 1Password, KeePass), enable two-factor authentication on your email and financial accounts first — your inbox is the master key to every "forgot password" flow. You can check whether your email appears in known breaches at Have I Been Pwned.
About This Tool's Randomness
- CSPRNG only, no fallback: passwords come exclusively from
crypto.getRandomValues, the browser's cryptographically secure source. JavaScript'sMath.random()is predictable and is never used — if Web Crypto is unavailable, the tool reports an error rather than silently degrading. - No modulo bias: mapping a random 32-bit integer onto a character pool with plain
%slightly favors early characters. This tool uses rejection sampling, so every character in the pool is exactly equally likely. - Nothing leaves your browser: generation is 100% client-side — no network request, no storage, no analytics on generated values. Verify it yourself in your browser's DevTools Network tab.
- Similar-character exclusion drops 0/O and 1/l/I for passwords that must be read aloud or typed by hand (Wi-Fi keys, device setup codes) at a small entropy cost; leave it off for autofilled passwords.
Frequently Asked Questions
How long should my passwords be?
12 characters (full charset) is the floor where offline brute force stops being practical. Use 16+ for high-value targets — primary email, banking, your password manager's master secret — and 32+ for API keys and machine-to-machine secrets nobody ever types.
Is it safe to generate passwords on a website?
This one runs entirely in your browser: pressing Generate sends no network request, and nothing is stored. The honest caveat for any web generator is that you're trusting the page's code; if your threat model excludes that, use your password manager's built-in generator — the underlying algorithm is the same.
What's batch generation for?
Provisioning initial passwords for multiple user accounts, seeding test fixtures, or creating unique secrets for several services in one sitting. Each password in a batch is sampled independently.
Why does it allow lengths as short as 4?
Short random strings have legitimate non-security uses — voucher codes, room codes, throwaway identifiers. For anything protecting an account, stay at 12 or above.