Why Math.random() Should Never Generate a Password

Every JavaScript environment ships two very different kinds of "random": Math.random(), designed for speed and statistical distribution, and the Web Crypto API's crypto.getRandomValues(), designed to be unpredictable even to someone who knows exactly how the generator works. A password generator needs the second kind specifically, and the reason why is more concrete than "crypto sounds more secure."

Two different design goals produce two different guarantees

Math.random() is typically implemented with a fast pseudorandom number generator (PRNG) optimized for speed and even statistical distribution — good properties for shuffling a game board or jittering an animation, where nobody is trying to predict the next value on purpose. Critically, most PRNG algorithms are deterministic: given the internal state, every future output is fully predictable, and in some implementations, that internal state can be reconstructed from a handful of observed outputs. That's a fine trade-off for its intended use and a disqualifying one for anything security-sensitive.

crypto.getRandomValues() instead draws from a cryptographically secure pseudorandom number generator (CSPRNG), which is specifically designed so that observing any number of past outputs gives no useful advantage in predicting future ones. That property — unpredictability even under active analysis, not just good statistical spread — is the actual bar a password generator has to clear, and it's the reason browsers expose a completely separate API for it rather than just making Math.random() "more random."

Why this matters concretely for a password

A password's entire job is resisting a guessing attack. If the generator producing it is predictable in principle — even if predicting it in practice requires unusual effort — that's a structural weakness baked into every password it ever produces, independent of length or character variety. A 20-character password generated from a predictable source can be weaker in practice than an 8-character one from a genuinely unpredictable source, because length and character variety only matter against brute-force guessing, not against an attacker who can reconstruct the generator's internal state directly.

Entropy still matters — just as the second layer of defense

Assuming a genuinely unpredictable source, the next question is how large the space of possible outputs actually is — this is what entropy measures: length multiplied by the base-2 logarithm of how many characters each position could be drawn from. A 12-character password from lowercase letters alone (26 possibilities per position) has meaningfully less entropy than a 12-character password mixing in uppercase, numbers, and symbols (roughly 90 possibilities per position), even though both look equally "random" to a human glancing at them. Entropy is what determines how many guesses an exhaustive brute-force search would need in the worst case — a separate concern from whether the generator itself is predictable, and one that only matters once the unpredictability question is already settled correctly.

Putting both pieces together

A trustworthy password generator needs both properties at once: a CSPRNG as the randomness source, so the output can't be reconstructed or predicted, and enough length and character variety, so brute-force guessing isn't feasible either. Missing either one undermines the other — no amount of length helps if the generator is predictable, and no amount of unpredictability helps if the password is too short or too narrow in character variety to resist guessing. That's exactly the combination thepassword generator on this site is built around: crypto.getRandomValues() for the randomness, and a live entropy estimate so the length/variety trade-off isn't a guessing game either.