A formula that only looks random
The random-number functions built into most programming languages — the plain Math.random() in JavaScript, for instance — are what's called pseudorandom number generators. They're entirely deterministic: starting from an internal state (a "seed"), they run that state through a mathematical formula to produce the next number, then update the internal state and repeat. Given the same starting seed, a pseudorandom generator produces the exact same sequence of numbers every single time, with no randomness involved in the arithmetic at all.
This sounds like it should be obviously useless for anything called "random", but the sequences these formulas produce genuinely do pass strong statistical tests for randomness — no simple pattern, no short-term repetition, a good spread across the possible range. For picking a random enemy spawn point in a game, shuffling a deck for a casual card game, or generating a sample dataset, a pseudorandom sequence is completely indistinguishable from true randomness in practice, and it has a real advantage: because it's deterministic, giving it the same seed again reproduces the exact same sequence, which is exactly what you want when you need to replay a game level or share a reproducible result with someone else.
Where predictability becomes a real vulnerability
The property that makes pseudorandomness useful for reproducibility is the same property that makes it dangerous for security. If an attacker can work out or guess a generator's internal state — sometimes as simple as knowing roughly when a program started, since some poor implementations seed from the current time — they can predict every "random" number it will ever produce from that point on. This isn't a theoretical risk: real, historical security failures have come from session tokens, password reset codes and cryptographic keys generated with an ordinary, non-cryptographic random function instead of a secure one.
This is why anything with real security stakes — a password, a session token, an encryption key, a one-time code — needs to come from a cryptographically secure random number generator instead. In a browser, that's the Web Crypto API's crypto.getRandomValues() function (and crypto.randomUUID(), which is built on it), which draws from the operating system's own entropy sources — hardware noise, timing jitter, and other genuinely unpredictable physical inputs the OS collects specifically for this purpose — rather than a predictable mathematical formula.
| Math.random()-style | crypto.getRandomValues()-style | |
|---|---|---|
| Source | A deterministic formula and internal state | The operating system's collected entropy |
| Reproducible from a seed? | Yes | No, by design |
| Predictable if state is known? | Yes | No |
| Safe for passwords or keys? | No | Yes |
| Good for games, sampling, shuffling? | Yes | Yes, but usually unnecessary overhead |
What a seed actually buys you
A generator that lets you enter or share a seed is explicitly trading away unpredictability in exchange for reproducibility — that's a deliberate, useful choice for the right use case, not a shortcoming. Being able to return to the exact same shuffled deck, the exact same generated character sheet, or the exact same set of random names by re-entering the same seed is only possible because the underlying generator is pseudorandom and deterministic in the first place; a truly, physically random source could never be asked to repeat itself on demand.
The honest way to think about it: pick a pseudorandom, seedable generator when you want a result you can return to, share, or reproduce exactly. Pick a cryptographically secure generator when the result needs to be genuinely unpredictable to anyone else, including someone who might guess or observe part of the process — and never use the first kind where the second kind is actually required.
Where this comes from
- The distinction between pseudorandom generators (like the Mersenne Twister family many languages use internally) and cryptographically secure generators is standard computer science and cryptography, described in most introductory cryptography texts and in the Web Crypto API specification itself.
- Real-world incidents from insufficiently random session tokens and cryptographic keys are documented in security research and CVE databases going back decades; the general pattern (predictable seeding, especially from system time) recurs across many unrelated incidents rather than being a single one-off case.