WheelMigo

Is a random name picker fair? We measured 7 million draws

You cannot see a picker's bias by watching it spin. You can only measure it. So we did.

Quick answer

Measured over 7,000,000 draws, WheelMigo landed on each of seven names within 0.015 percentage points of a perfect one-in-seven, because it uses crypto.getRandomValues with rejection sampling. Run the same test on a common shortcut — one random byte modulo the number of names — and the first four of seven names come up 2.78% more often, a real skew you can measure but never see on screen. The twist: that same shortcut is perfectly even with eight names, so you cannot judge a picker from the outside — only from how it draws.

Key points

  • Over 7,000,000 draws WheelMigo stayed within 0.015 percentage points of an even one-in-seven for every name.
  • The naive "one byte modulo n" shortcut made four of seven names 2.78% more likely — a real, measured skew, not a rounding artefact.
  • With eight names the same shortcut was perfectly even, because 256 divides by 8 — so a picker's fairness depends on your list size.
  • Rejection sampling is why WheelMigo has no such skew: at seven names it discards fewer than one raw draw in a billion, then keeps the remainder.

Every name picker says it is random. The word is free to print and impossible to check by eye — a wheel that favours the top of your list looks exactly like one that does not. The only way to know is to draw a very large number of times and count. So we took the exact selection code that runs inside WheelMigo, ran it 7,000,000 times over a list of seven names, and ran a popular shortcut the same 7,000,000 times next to it.

How we tested

Both methods drew from the same seven-name list, 7,000,000 times each, and we tallied how often each name won. Method one is WheelMigo's real algorithm: ask the browser's crypto.getRandomValues for a 32-bit number, throw away the small leftover range that would not divide evenly (rejection sampling), and keep the remainder. Method two is the tempting one-liner a quick build often uses: take a single random byte, 0 to 255, and use its remainder modulo the number of names. Same list, same number of draws, same machine — only the selection method differs, so any gap between them is the method, not luck.

The result: WheelMigo lands even, the shortcut does not

A perfectly fair picker gives each of seven names 14.29% of the wins. Here is what 7,000,000 draws produced for each method (percentages of all wins):

Name (of 7)WheelMigoNaive byte % nEven target
Name 114.28%14.45%14.29%
Name 214.28%14.44%14.29%
Name 314.30%14.47%14.29%
Name 414.30%14.45%14.29%
Name 514.27%14.08%14.29%
Name 614.28%14.05%14.29%
Name 714.29%14.06%14.29%

WheelMigo's biggest gap from a perfect one-in-seven was 0.015 of a percentage point — ordinary sampling noise that shrinks further the more you draw. The shortcut's biggest gap was 0.24 of a point, about sixteen times larger, and it was not noise: names 1 through 4 were consistently high and names 5 through 7 consistently low. A name in the favoured group came up 2.78% more often than one in the unfavoured group, every run.

Where the shortcut's bias comes from

A byte holds 256 values. Divide 256 by 7 names and you get 36 remainder 4: the numbers 0, 1, 2 and 3 each land 37 times across the byte's range, while 4, 5 and 6 land only 36 times. Map those remainders onto your list and the first four names inherit the extra chance. It is invisible on any single spin and on any short session — but over a school term of daily cold-calls, or a raffle with hundreds of tickets, "the top of the list wins a bit more" is exactly the kind of quiet unfairness a picker is supposed to remove.

The trap: with eight names the same shortcut looks flawless

We reran the shortcut with eight names instead of seven. This time it was even — its largest gap was 0.02 of a point, as clean as WheelMigo's. The reason is arithmetic: 256 divides by 8 exactly, so there is no leftover to favour anyone. That is the real lesson. The same picker can be biased with six or seven names and perfect with eight, and nothing on screen tells you which list you are in. Fairness you cannot see is not fairness you can trust; it has to be built into how the draw is made, not left to the size of today's list.

What WheelMigo does instead

Rather than a single byte, WheelMigo draws a full 32-bit number — a range of about 4.29 billion — and discards the tiny sliver at the top that would not divide evenly before taking the remainder. At seven names only four of those 4.29 billion values fall in the discard zone, so fewer than one draw in a billion is ever thrown away; across our 7,000,000 draws, not one was. That is why every name sat on its exact share regardless of how many names were on the list. The mechanism, step by step, is in “How WheelMigo actually picks a name”; this article is the measurement that backs it up.

Why a fraction of a percent matters

For one spin at a party, none of this matters. For a draw that repeats — a teacher choosing who answers every day, a giveaway that runs for weeks, a rota that decides turns — a 2.78% standing advantage compounds into real, noticeable unevenness, and it always favours the same people. That is the whole reason to use a dedicated picker instead of guessing, and the reason the selection method, not the animation, is the part worth checking. Honest boundary, unchanged: WheelMigo is a browser tool for casual and classroom draws, not a certified, audited service for regulated prizes or lotteries.

How this works

We ran WheelMigo's actual selection function — crypto.getRandomValues for a 32-bit integer, rejection sampling to remove modulo bias, then remainder modulo the entry count — 7,000,000 times over a seven-name list, and tallied wins per name. Alongside it we ran a naive alternative (one random byte modulo the entry count) for the same 7,000,000 draws, then repeated both with an eight-name list. Percentages are wins divided by total draws. The test is reproducible: the only difference between the two columns is the selection method, and the byte method's skew matches the arithmetic of 256 divided by the list size.

Frequently asked questions

Is an online name picker actually random, or can it be rigged?
It depends entirely on the selection method, which you cannot see. Measured over 7,000,000 draws, WheelMigo gave every name an even share using crypto.getRandomValues with rejection sampling. A picker that takes a shortcut can quietly favour some list positions — we measured a 2.78% edge for four of seven names — without anything looking wrong on screen.
Can the order of names in my list change who gets picked?
With WheelMigo, no — position had no measurable effect across 7,000,000 draws. With a naive "byte modulo n" picker it can: the first few names inherit a small extra chance whenever the list size does not divide the random range evenly.
Which list sizes make the shortcut's bias worst?
Any size that does not divide the random range cleanly. With a single byte (256 values), seven names skews and eight does not. That is exactly why fairness has to come from the draw method rather than from happening to have a convenient number of names.
Does this make WheelMigo safe for a prize giveaway?
For casual and classroom draws, yes — the selection is uniform and unbiased. For anything with legal or financial stakes, use a service specifically built and audited for certified random draws; a browser tool, however fair its draw, is not certified evidence.

References

  1. MDN — Crypto.getRandomValues()
  2. Wikipedia — Rejection sampling
  3. Wikipedia — Modulo bias (uniform random within a range)

← All articles