Random Number Generator

Where the numbers come from

Draws use crypto.getRandomValues, the browser's cryptographically secure generator, which is seeded from entropy the operating system collects and is designed so that observing output tells you nothing useful about what comes next.

The obvious alternative, Math.random, is a different kind of thing. It is a fast pseudo-random generator - typically xorshift128+ - built for speed, seeded from something like clock state, and with internal state small enough that a handful of outputs can be enough to recover it and predict the rest. The ECMAScript specification says outright that it must not be used for cryptographic purposes.

For picking a raffle winner the difference rarely matters. It is used here anyway because there is no cost to it, and because a generator that is only sometimes trustworthy is harder to reason about than one that always is.

Modulo bias

The simple way to squeeze a random value into a range is to take it modulo the range size, and it is subtly wrong whenever the range does not divide the generator's range evenly.

Take a random byte, 0 to 255, and ask for a number from 1 to 10. There are 256 possible bytes and 10 possible answers, and 256 is not a multiple of 10. Six of the ten answers get 26 bytes mapping to them and the other four get 25, so the first six come up about four per cent more often than the rest. With a range of 1 to 100 the skew is larger; with 1 to 200 it is larger still.

The fix is rejection sampling: work out how many values at the top of the generator's range would cause the imbalance, discard any draw that lands there, and try again. Here that means values above the largest exact multiple of the range are thrown away rather than folded in. It costs an occasional extra draw and it makes every number in the range exactly equally likely. The same routine backs the password and UUID generators on this site.

Drawing without repeats

No-repeat mode samples without replacement, which is what you want for lottery numbers, prize draws and picking a random subset of a list. Once a value has been drawn it is removed from the pool, so no number appears twice in a set.

That requires the range to hold at least as many values as you asked for - six unique numbers cannot come from a range of four - and the tool says so rather than looping forever. Note that this constrains the set, not the order: the numbers are still drawn in a random sequence, so the result is a shuffle of a random subset rather than a sorted sample. Sorting is available separately when you want the result in order.

What this is not for

It is a good tool for raffles, dice, test fixtures, picking which task to do first, and any of the hundred small decisions people delegate to chance.

It is not the tool for generating a key, a password or a token, not because the randomness is inadequate but because those need a specific length and alphabet - use the password generator for that. It is also not suitable for a public draw where participants have to trust the result: a number appearing on a page proves nothing to anyone who did not watch it appear, and a verifiable draw needs a published seed and a commitment made before the draw, which is a different design entirely.

Pseudo-random, cryptographic, and truly random

A pseudo-random generator is a deterministic function: given the same starting state it produces the same sequence forever. That is a feature for simulations, where reproducibility matters, and a liability where anyone might try to predict the next value. Math.random in JavaScript is typically xorshift128+, fast and with a small internal state that can be recovered from a handful of outputs.

A cryptographically secure generator is built so that observing any amount of output gives no useful information about the rest. It is seeded from entropy the operating system collects - timing jitter, interrupt patterns, hardware instructions such as RDRAND - and reseeded periodically. crypto.getRandomValues in a browser and /dev/urandom on Unix are the usual interfaces, and both are fast enough that the security is effectively free.

True randomness, from a physical source such as thermal noise or radioactive decay, exists in hardware modules and in services like random.org. For almost every purpose it is unnecessary: a well-seeded cryptographic generator is indistinguishable from it by any test anyone can run.

Shuffling a list without biasing it

The intuitive shuffle - sorting by a random comparator - is wrong, and wrong in a way that passes casual inspection. Comparison sorts assume a consistent ordering, so a random comparator produces distributions that favour some permutations heavily, and the result differs between sort implementations. It looks shuffled and is not.

The correct algorithm is Fisher-Yates: walk the list from the end, and for each position pick a random index between zero and that position inclusive, then swap. Every permutation is equally likely and it runs in linear time. Nearly every language's standard library has a correct implementation; where it does not, the loop is four lines.

Selecting a subset is the same operation stopped early: shuffle the first k positions and take them. Doing it by drawing random indices and discarding duplicates works but degrades badly when k approaches the list length, which is the point at which most improvised implementations start looping for a noticeable amount of time.

What random sequences actually look like

People are poor judges of randomness, and the mistake runs one way: real random data contains far more clustering than intuition allows. In a hundred coin flips, a run of six or seven heads is likely rather than suspicious, and a sequence with no long runs is the one that was probably made up.

This is why music shuffle features on streaming services are usually not random at all. True shuffling plays the same artist three times in a row often enough that users report it as broken, so the algorithms deliberately spread artists out - less random, more like what people mean by shuffled.

Two related intuitions worth resisting: the gambler's fallacy, which expects a result to become due after a run of the opposite, and the birthday effect, which makes collisions far more likely than expected - twenty-three people give even odds of a shared birthday. Both are consequences of the same misjudgement about how clumpy randomness is.

When you want the same numbers every time

Simulations, procedurally generated content and statistical work all need reproducibility: the same seed producing the same sequence, so a result can be re-examined and a bug reconstructed. A cryptographic generator is exactly the wrong tool there, because it cannot be seeded deliberately.

The usual approach is a small, well-tested pseudo-random generator - PCG, xoshiro, or the Mersenne Twister in older code - seeded explicitly and logged. In tests, printing the seed on failure turns an intermittent failure into a reproducible one, which is the difference between a bug that gets fixed and a test somebody disables.

Keep the two generators separate and never let a seeded one leak into security-relevant code. The pattern that causes trouble is a utility function used for both shuffling test data and generating tokens, at which point a deterministic sequence protects something it should not.

Making a draw people will accept as fair

Fairness has two parts: the mechanism and the evidence. The mechanism here is sound - a cryptographic source with rejection sampling, so every value in the range is equally likely. The evidence is what a page cannot supply, because a number appearing on a screen proves nothing to anyone who was not watching.

Where a draw has money or obligations behind it, the standard construction is commit-and-reveal: publish a hash of the entry list and a seed before entries close, run the draw with a public method afterwards, and publish the seed so anyone can recompute the result. It converts trust in the organiser into arithmetic anyone can check.

For the everyday cases - who presents first, which task to start, who gets the last ticket - none of that is needed. The relevant fairness is that everyone in the room can see the same result appear at the same time, which is why a visible draw beats a number someone reads off their own screen.