How Random Draws Work

A computer cannot invent randomness

A computer exists to follow instructions precisely and return the same output for the same input. That is the whole point of the machine, which means it cannot spontaneously produce genuinely unpredictable values.

The workaround is a pseudo-random number generator. It takes one starting value, the seed, and repeatedly applies a fixed calculation to produce a sequence that looks random from the outside. Feed in the same seed and you get exactly the same sequence back.

Genuine unpredictability has to come from outside the computation. Operating systems gather physically unpredictable events, such as the timing between keystrokes, disk response times, and hardware noise, into an entropy pool that seeds the generators.

How pseudo-random generators work

The easiest one to picture is the linear congruential generator. Multiply the current value, add a constant, take the remainder, and that is your next value. It is simple but leaves detectable patterns in the low bits, which is why it has fallen out of use.

Modern browsers mostly use something from the xorshift128+ family for Math.random(). It updates a 128-bit state with bit shifts and exclusive-or operations, giving a much longer period and much better statistical behaviour than an LCG.

Quality is judged on three things: uniformity, meaning every value appears equally often; period, meaning how long before the sequence repeats; and correlation, meaning whether one value reveals the next. Modern generators pass all three and are statistically hard to distinguish from true randomness.

How far ordinary randomness can be trusted

For anything without significant stakes, it is entirely adequate. Splitting groups, choosing lunch, setting speaking order, rolling dice in a game: the quality of the generator is never the weak point in any of these.

The limitation is predictability. Observe enough output and the internal state can be reconstructed, at which point the next value is known. Published techniques exist for recovering xorshift128+ state from a handful of outputs.

Seeding is the other limitation. If the seed comes from something predictable such as the clock, two programs starting at the same moment can produce identical sequences. Browsers avoid this by seeding from system entropy.

Cryptographically secure randomness

When there is a real incentive to predict the outcome, you need a cryptographically secure generator. In the browser that is crypto.getRandomValues().

Its defining property is that no amount of observed output lets you compute the next value. It seeds from the operating system entropy pool and uses cryptographic functions whose state cannot be run backwards.

Password generation, authentication tokens, and prize draws with money attached all belong in this category, because knowing the result early would be worth something. The password generator on this site uses it.

Choosing between them

The test is simple: would somebody gain from knowing the result in advance? If yes, use cryptographic randomness. If no, ordinary pseudo-randomness is fine.

Speed is the other factor. Cryptographic generation is slower, which matters if you need hundreds of thousands of values for a simulation. For anything from a handful to a few hundred, the difference is imperceptible.

• Ordinary randomness is fine: group splitting, ordering, game dice, choosing a meal
• Use cryptographic randomness: passwords, auth tokens, prize draws with money, security keys

Seeds and reproducibility

The same seed producing the same sequence is not purely a weakness. In research and simulation, being able to reproduce a result is what makes it verifiable, so recording the seed is standard practice.

Draws can use this too. Publish the seed alongside the entry list and the algorithm and anyone can reproduce the result and confirm it.

The catch is that publishing a seed in advance also lets people compute the result in advance, so sequencing matters. The usual solution is to publish a hash of the seed first and reveal the seed itself after the draw.

Clustering is not bias

The most common misreading of random output is clustering. Flip a coin twenty times, see five heads in a row, and something feels broken. In fact a run of five somewhere in twenty flips happens roughly a quarter of the time.

When people invent a random-looking sequence in their heads, the result is too evenly spread. Real randomness bunches up, leaves gaps, and bunches again, the same way stars form clusters rather than spacing themselves out across the sky.

So the same name coming up again is not evidence of bias on its own. Detecting real bias takes hundreds of trials and a look at the distribution, which is why using an algorithm already proven correct is the more practical route.