A password’s resistance to guessing comes down to one number: how many possible passwords exist in the space it was drawn from, expressed as entropy in bits. A truly random password of length L drawn from a character set of size N has entropy L × log₂(N) bits, and every additional bit doubles the number of guesses an attacker needs on average.
Why length beats complexity
Adding one more character to the length multiplies the search space by the size of the character set — for a full set of about 90 printable characters, that is roughly a 90-fold increase. Adding an entire new character class (say, requiring at least one symbol) barely moves the character-set size at all if the length stays the same. A 20-character password using only lowercase letters has more entropy (about 94 bits) than a 10-character password using every character class combined (about 65 bits). Length is the dominant factor by a wide margin.
Randomness has to come from the right place
This generator uses crypto.getRandomValues, the Web Crypto API’s cryptographically secure random number source, rather thanMath.random(). The distinction matters: Math.random() is good enough for a dice-roll animation but its internal state can, in principle, be reconstructed from enough observed outputs, which makes it unsuitable for anything security-relevant. Every password here is generated locally in your browser and never transmitted anywhere.
What entropy does not protect against
- Reused passwords. A single leaked database exposes every account that reused the same password, regardless of how strong it was.
- Phishing. A perfectly random password typed into a fake login page is compromised instantly — entropy only defends against guessing, not deception.
- Weak storage on the far end. If a service stores passwords improperly, the strength of what you sent them is irrelevant.
A password manager that generates and stores a unique high-entropy password per site addresses the reuse problem, which is generally the larger practical risk compared with entropy alone.
The crack-time estimate
The time-to-crack figure assumes an offline attack — the attacker has obtained a password hash and is guessing as fast as their hardware allows, taken here as ten billion guesses per second, a reasonable figure for GPU-accelerated cracking against a fast, unsalted hash. Real systems that hash passwords properly (with bcrypt, scrypt or Argon2) impose a deliberate slowdown that can push this estimate up by several orders of magnitude — and conversely, a system using a fast, poorly chosen hash function makes real-world cracking faster than this estimate suggests.