Developer's Guide to Random Password Generator: Best Practices and Examples

Password strength is fundamentally a question of entropy: how many guesses would an attacker need, on average, to find the right password by brute force? A password's entropy in bits is calculated as log2(charset_size ^ length), which means both the size of the character pool and the length contribute, but length dominates for realistic charset sizes. A 12-character password drawn from a 94-character set (upper, lower, digits, symbols) has roughly 78 bits of entropy — computationally infeasible to brute-force with current hardware. A 12-character password using only lowercase letters has closer to 56 bits, which is meaningfully weaker despite being the same length. But entropy math only holds if the randomness generating the password is actually unpredictable. This is where Math.random() becomes a liability rather than a convenience: it's a fast, statistically well-distributed PRNG intended for simulations and games, but its internal state is not designed to resist prediction, and in principle an attacker who can observe enough outputs or knows implementation details could narrow down future values. For anything security-sensitive — passwords, tokens, session IDs, encryption keys — the correct primitive is a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG), which in the browser means window.crypto.getRandomValues(), backed by the operating system's entropy source.

[!TIP] Need to generate a strong password right now? Try our free, local Random Password Generator to create passwords from window.crypto.getRandomValues() completely offline.

---

Why Math.random() Is the Wrong Tool for Secrets

Math.random() and window.crypto.getRandomValues() solve different problems, even though both "return random-looking numbers":

	Math.random()	crypto.getRandomValues()
Design goal	Statistical distribution, speed	Unpredictability, resistance to prediction
Suitable for	Simulations, games, sampling	Passwords, tokens, keys, nonces
Seed/state exposure	Implementation-dependent, not designed to be secret	Sourced from OS-level entropy pools

Using Math.random() to generate a password reset token or API key is a well-known anti-pattern precisely because the generator was never designed to resist an adversary trying to predict its output.

Character Sets and Practical Entropy

Digits only (10 chars):           length 12 -> ~40 bits
Lowercase only (26 chars):        length 12 -> ~56 bits
Upper + lower (52 chars):         length 12 -> ~68 bits
Upper + lower + digits (62 chars): length 12 -> ~71 bits
Full symbol set (~94 chars):      length 12 -> ~79 bits

As a practical guideline, aim for at least 60-80 bits of entropy for anything meant to resist offline brute-force attempts, which generally means a length of 12-16 characters combined with a full mixed-character set — or longer if you're restricted to a smaller charset.

A Note on Passphrases

Length matters more than complexity rules once you're past a reasonable minimum. A long passphrase built from several random dictionary words (correct-horse-battery-staple-style) drawn from a large wordlist via a CSPRNG can have comparable or greater entropy than a shorter, symbol-heavy password, while being easier for a human to remember and type. The entropy math is the same regardless of the character/word pool — what matters is the pool size and the number of independently random choices.

---

Conclusion

A password generator is only as trustworthy as its source of randomness, and the difference between a statistical PRNG and a CSPRNG is invisible in a UI but decisive under actual attack. When generating anything that needs to resist a determined adversary rather than just look random, confirm the tool is drawing from the browser's or OS's cryptographic entropy source, not a general-purpose Math.random() call.