“It is random” is an assertion, not a fact. Two things have to be true for a selection to be fair: the source of the numbers must not be predictable, and every option must be equally likely.
Both are implementable, both are commonly got wrong, and they fail independently. A tool can have an excellent random source and a biased mapping, or a perfectly uniform mapping fed by predictable numbers.
Where Randomness Comes From
Genuine randomness comes from physical processes that are not determined by prior state:
- Radioactive decay — the moment an atom decays cannot be predicted
- Thermal noise — random voltage fluctuations in a resistor
- Atmospheric noise — background static from lightning activity
- Quantum measurement — outcomes that are genuinely indeterminate
A computer cannot observe these directly. What it does is sample a hardware generator — /dev/urandom and its equivalents — which is itself seeded from physical processes. That is a true random number generator.
The far more common case is a pseudo-random number generator: a deterministic algorithm producing a sequence that merely looks random.
next = (previous × multiplier + increment) mod modulusThe critical property is not subtle. If you know the algorithm and the seed, you can compute every value the sequence will ever produce. Not approximately — exactly. This is why Math.random(), used by most websites, is unsuitable for anything that matters: its output is determined by internal state, and recovering that state from observed outputs makes every future result predictable.
The Middle Ground That Decides the Question
Modern platforms do not use raw hardware entropy per call. They use a cryptographically secure PRNG — deterministic, but seeded from hardware entropy and designed so that observing outputs does not reveal the state.
| Hardware TRNG | CSPRNG | Ordinary PRNG | |
|---|---|---|---|
| Based on physical entropy | Yes | Yes | No |
| Deterministic given the state | No | Yes | Yes |
| Output reveals the state | No | No | Yes |
| Suitable for a prize draw | Yes | Yes | No |
A CSPRNG is deterministic in exactly the sense every piece of software you use is deterministic. What makes it acceptable is that its state is not recoverable from what it has already emitted.
Browsers expose this through crypto.getRandomValues(). It is the source the draws here use.
Uniformity Is a Separate Problem
Having a good source is not enough. The mapping from a random number to a choice can still be biased, and this is the mistake most tools make.
The naive approach — scale a random float from 0 to 1 onto the range — biases the low end. With 40 names, some random values land past the end of the last bucket, and if they are clamped rather than discarded, the first name comes up slightly more often than the last.
The bias is small enough that nobody notices, which is precisely why it survives in most implementations.
The correct approach is rejection sampling: draw, and if the result falls in the incomplete final bucket, discard it and draw again. The distribution becomes exactly uniform, so every entry has a 1/N chance — including in a 40-name draw where a scaled-float implementation gives the first name a very slightly higher probability.
The same technique appears in the short-ID generator here, where the acceptance rate is 252/256 and the resulting bias is about two parts in ten million. Small enough to be irrelevant, and small enough that a careless implementation would have gone unnoticed — which is exactly why it is worth measuring.
Three Human Failures That Are Not the Tool’s
Gambler’s fallacy. After five heads in a row, tails feels due. Each draw is independent. The coin has no memory of being unfair, and the correct probability after five heads is still exactly 1/6 per face.
Clustering illusion. Streaks in random data feel patterned because you are looking for them. Three identical results in a row happens far more often than intuition suggests. And truly random data looks lumpy over short runs — a sequence that looks perfectly even is more likely to be fabricated than genuine.
Birthday paradox. In a group of 23 people, two likely share a birthday. This is arithmetic, not psychology, but it illustrates why people are so bad at estimating randomness: the individual probabilities are tiny and they multiply.
The common thread is that one observation proves nothing, in either direction. A draw that looked odd is as uninformative as one that looked tidy.
The Two Failures That Matter Most in Practice
Having traced the mechanism, it is worth naming what actually goes wrong when a selection is disputed — and neither of these is about the source.
The operator overrode the result. Re-rolling, hand-correcting, skipping an absent name mid-draw. A perfect generator and a modified outcome is still a modified outcome, and it is visible to anyone who watched.
The pool was not the published pool. Adding a name, or quietly excluding one, changes the selection regardless of the algorithm.
Both are process failures, and both are what a recorded draw prevents. That is why recording with the participant list in frame is worth more than any technical property: it forecloses both.
Where This Level of Rigor Is Warranted
For choosing a lunch, none of this matters. Any generator produces an acceptable lunch.
It becomes load-bearing when there is a stake, a reputation, or a legal dimension:
- Prize draws and contests. A verifiable outcome is the point
- Employee or duty assignment. People will inspect the process
- Scientific and clinical randomisation. The field’s standard is documented, seeded, reproducible randomness
- Regulatory and audit contexts. Documented randomness is frequently a requirement, not a preference
The requirements in all of these are the same four, and they are short: the pool is fixed and published, the weights are published if any exist, the source is not predictable, and the result is recorded with the pool visible.
How to Check It Yourself
You cannot audit a CSPRNG in a browser tab, but you can reason about the mechanism, and that is enough.
Ask what the source is. If the answer is “a random function”, ask whether it is the predictable one. crypto.getRandomValues() is a specific, checkable answer.
Ask how uniformity is achieved. If the answer involves scaling a float onto a range with no mention of rejection sampling, the mapping is probably biased. Smallly, but measurably.
Ask what the operator could have changed. If nothing, the result is defensible. If a name could be skipped or the draw re-run, it is not — regardless of the source.
The fairness page covers the implementation on this site in more detail. It is worth reading once if you are choosing a tool for a decision that will be questioned.