How Fair Random Picks Work: Wheels, Name Draws and Dice

A raffle, a team split, and a dice roll all rest on the same question: is every outcome actually equally likely, or does the code have a hidden lean? The wheel spinner, the name picker, the random number generator and the coin flip and dice roller all answer that question the same way, by drawing from the browser's cryptographic random source instead of a predictable formula, and three of the four go a step further with a specific fix called rejection sampling. None of that is visible in the interface. It is visible in the code, and it is worth knowing what it actually buys you before you run a draw nobody can dispute.

Why the source of randomness matters

Every one of these tools calls crypto.getRandomValues, not JavaScript's ordinary Math.random. That distinction, and the modulo bias problem that rejection sampling exists to fix, gets a full worked explanation with real numbers in the guide on password length versus complexity, which covers the same primitive in the password generator. The short version: Math.random is a fast, deterministic formula never designed to resist prediction, while crypto.getRandomValues pulls from the operating system's cryptographic entropy pool, the same source used to generate encryption keys. For a raffle, a coin flip, or a team split, that is the difference between a draw you can defend and one you cannot.

Four tools, four techniques for the same guarantee

Reading the code behind each tool shows they do not all solve fairness the same way:

A Fisher-Yates shuffle works backward through a list, swapping each position with a randomly chosen earlier one, and it is the standard way to turn a list into a uniformly random order in one pass. Rejection sampling solves a narrower problem: mapping a 32-bit random number onto a smaller range like 1 to 6 with a plain modulo slightly favors low results, because 2³² rarely divides evenly by the range size. The fix is to throw away the small band of values that would cause that skew and draw again, which is exactly what the name picker, the number generator and the dice roller do before every modulo.

Two worked examples

Take a 24-entrant raffle on the wheel spinner with one prize. Paste 24 names, click Spin, and the tool draws a single random index from 0 to 23 before the wheel even starts turning; the six-to-eight rotations that follow are calculated in advance to land that segment under the pointer. The animation has no influence on the outcome, only on how long you wait to see it.

Now take a 17-person group that needs 4 even-ish teams, on the name picker. Set Teams to 4 and click Split into teams. The tool shuffles all 17 names once with Fisher-Yates, then deals them round-robin: name 1 to Team 1, name 2 to Team 2, name 3 to Team 3, name 4 to Team 4, name 5 back to Team 1, and so on. Seventeen does not divide evenly by four, so the deal produces Team 1 with 5 people and Teams 2 through 4 with 4 each. The extra person always lands on the earliest team, and the imbalance is never more than one person, because the round-robin deal only runs out of names partway through a single lap.

The one corner the wheel cuts, and why it barely matters

The wheel spinner's random index comes from a plain modulo with no rejection step, unlike the other three tools. In principle that is a real bias: with 2³² possible raw values, a range that does not divide it evenly gives the low indexes a very slightly better chance. The size of that gap is easy to compute. For a full 100-entry wheel, 2³² mod 100 is 96, meaning 96 of the 100 possible remainders get one extra raw value out of roughly 42.9 million each, and the other 4 remainders get none extra. The relative size of that edge is about 1 in 42.9 million, or roughly 0.0000023%. At the wheel's actual entry cap the effect is smaller still. It is a real asymmetry and also not one anybody could exploit or even detect by watching results.

Streaks are not proof anything is broken

The coin flip and dice roller keeps a running tally for a reason: fair randomness produces streaks, and streaks read as suspicious even when nothing is wrong. Flip a fair coin 100 times and there is roughly an 81% chance of at least one run of five heads or five tails somewhere in the sequence, a figure that holds up under direct simulation of the same 50/50 draw the tool makes. Five in a row feels rigged. It is actually close to guaranteed over that many flips, and it is exactly the kind of thing a short session will not reveal, which is why the tally exists: run fifty or a hundred flips and watch the heads percentage drift toward 50% instead of trusting the first five.

Where these tools stop being enough

None of the four remembers anything between sessions. The wheel and the name picker both forget their lists on refresh, so there is no way to exclude last week's winner automatically; delete their line by hand before the next draw. Weighting is not supported anywhere either: giving one raffle entry three times the odds means pasting that name on three separate lines, which works but shows up as three visible, identical segments or lines rather than one hidden weight. The wheel also removes every line that exactly matches a winner's text when you click Remove winner, so two entrants both typed as "Sam" will both disappear on one removal. None of this affects fairness. It affects what you have to do by hand around the edges of a fair draw.

What to do

• Use the wheel spinner for a visible, crowd-facing draw where the spin itself is part of the moment.
• Use the name picker for winners or team splits where you want the fairness argument to rest on a named algorithm, not an animation.
• Use the random number generator with no repeats for ticket-number raffles, and the coin flip and dice roller for anything that maps onto a simple face or number.
• Screenshot the result of any draw that matters, since none of these tools keeps a history once the page reloads.