How to use it
- Set the length and how many passwords you want.
- Choose which character sets to include.
- Copy the result. Press Regenerate for a fresh batch.
Every selected set is guaranteed to appear at least once, then the remaining positions are filled from the combined alphabet and the whole thing is shuffled.
Length beats complexity
The strength of a random password is length × log2(alphabet size) bits. Both factors count, but they are not equally cheap.
| Setup | Alphabet | 12 chars | 16 chars | 20 chars |
|---|---|---|---|---|
| lowercase only | 26 | 56 bits | 75 bits | 94 bits |
| + uppercase + digits | 62 | 71 bits | 95 bits | 119 bits |
| + symbols | 86 | 77 bits | 102 bits | 128 bits |
Read across a row and each four characters buys roughly 19–24 bits. Read down a column and adding every symbol on the keyboard buys about 7 bits total. This is why complexity rules — "one uppercase, one digit, one symbol" — are a poor policy: they add little entropy while reliably producing Password1!, which is in every cracking dictionary. Modern guidance (NIST SP 800-63B) drops composition rules and emphasises length instead.
For anything stored in a password manager, 20 characters from the full alphabet is comfortably beyond brute force and costs you nothing, because you will never type it.
Where random numbers come from
Math.random() is a fast pseudo-random generator seeded from an unspecified source. Its output is statistically fine for animations and completely unsuitable here: given enough output an attacker can recover the internal state and predict every subsequent value. Password generators built on it have been broken exactly this way.
This tool uses crypto.getRandomValues, which draws from the operating system's cryptographic entropy pool. It also rejects raw bytes that fall outside the largest multiple of the alphabet size — without that step, a simple byte % 86 makes the first few characters of the alphabet slightly more likely than the rest. The bias is small and it is also unnecessary.
What the crack-time figure is worth
The estimate assumes an attacker who has your password hash and can try 10^12 candidates per second. That is realistic for a leaked database hashed with something fast like unsalted SHA-256 on GPU hardware.
It does not apply to guessing against a live login form — rate limiting and lockouts make that vastly slower — and it does not apply if the hash was made with bcrypt, scrypt or Argon2, which are deliberately slow and can reduce the attacker's rate by six orders of magnitude or more.
So read the number as a floor, and remember it only measures brute force. A strong password reused across sites is defeated by credential stuffing the moment any one of those sites is breached, regardless of entropy. Unique passwords in a manager, plus a second factor on anything that matters, do more for you than another eight bits.