Wheel of Names: how to make 'just spin it' actually fair

The spin is theatre. The math is fair (or not).

Here is a thing nobody tells you about wheel pickers: the spin itself is not randomness. It is animation. The wheel has already chosen the winner before the first frame plays — the code generates a random index, looks up the winning slice, and then rotates the wheel by exactly the right angle to make that slice land at the pointer. The deceleration curve, the wobble, the satisfying click as it slows down, all of that is decoration. The random number was decided in the first millisecond after you clicked Spin.

This sounds underwhelming until you realise the alternative is worse. A wheel that is "really" spinning — actually physically simulating angular momentum and friction — is hard to get right. The friction model has to be uniform, the starting velocity has to be uniformly random, and the angle landed on has to be uniformly distributed across all the slices. Get any of those wrong and you have a biased wheel. Picking the winner first and animating to it lets the underlying randomness be provably uniform, which is what you actually wanted in the first place.

Why most wheels are not actually uniform

The standard mistake is using Math.random() and the modulo operator to pick a list index. The code looks like this: const winner = items[Math.floor(Math.random() * items.length)]. This looks fine. It is fine for casual use. It is also subtly biased, because Math.random() is implemented as a pseudo-random number generator with a finite period, and on some browsers the lower bits are notoriously non-uniform — meaning some indices come up slightly more often than others.

For a five-person Secret Santa drawing this does not matter. For a high-stakes giveaway with twelve thousand entries, it does. The fix is to use crypto.getRandomValues() — the browser's built-in cryptographic random source — and to use rejection sampling instead of modulo. Rejection sampling means: ask the source for a number in a power-of-two range bigger than your list, and if you happen to draw a number outside the list, throw it away and try again. This eliminates "modulo bias" entirely.

Our Spinner Wheel Picker uses exactly this approach. The winning index is chosen by crypto.getRandomValues + rejection sampling, the angle is computed from that index, and only then does the visible animation start. The math is uniform, provably, and the show is just to make the result feel earned.

Multi-wheel: combined picks vs independent picks

A common ask is "spin a person and a task at the same time." A naive multi-wheel will spin both wheels with the same random seed and just display them side by side. That looks fine, but it has a subtle problem: if you ever want the two picks to influence each other (e.g. "the person picks first, then the task is from a subset that matches"), you need them to be independent draws, not coupled.

The right model for combined picks is to draw each wheel independently, then animate them in parallel. The Multi-Wheel Picker is built around this — you can spin two or three lists side by side, and each one draws independently. So "person + task + duration" produces a fair combination, and you can re-spin one wheel without disturbing the others if you want to keep one of the picks.

Lottery balls: same math, different theatre

Some events want a different kind of drama. A wheel feels good for "one winner from twenty names." A bouncing-balls lottery feels good for "one winner from one hundred names" — there is something about the physics of balls in a bin that reads as more random, even though it is computed the same way.

The Lottery Ball Pit Picker is a deliberate stylistic alternative to the wheel. The math is identical — pick a random winning index up front, then animate to make that ball drop out — but the presentation is very different. It is also kinder to large lists. A wheel with one hundred slices is unreadable; a ball pit with one hundred bouncing balls is delightful. For livestreams or in-room events with bigger groups, the ball pit often plays better than the wheel.

Reduced motion and accessibility

The flip side of "the spin is theatre" is that some people physically cannot watch the theatre. Vestibular disorders, migraines, and motion sensitivity make long-spinning wheels actively painful. Operating systems expose a prefers-reduced-motion media query for exactly this case.

A well-built wheel respects that setting. When the browser reports reduced motion, the wheel should still pick a winner — that is the whole point — but it should skip the animation. The same goes for the ball pit: balls render statically, the winning ball appears highlighted, and the user is told who won without needing to watch the bounce. We implement both of these in the tools above, and we recommend testing anything else you build against the same toggle.

When NOT to use a wheel

Wheels are great for events where the dramatic reveal is part of the value: live streams, classroom rituals, draw-the-winner moments. They are terrible for anything where you want to record the result, distribute it programmatically, or pick more than one winner at once. For those cases, use a list-based picker — the Random List Shuffler for a full ordering, the Random Multiple Winners tool for N distinct winners, or the Raffle / Giveaway Drawer for weighted multi-ticket draws.

The reason is simple: spinning a wheel three times in a row to find three winners is slow and visually awkward, and you also have to remember to remove the previous winner each time. A purpose-built multi-winner picker handles all of that in one click and is faster to copy into a spreadsheet afterwards.

The short version

Spinning wheels are great when the drama is part of the point. Behind the animation, the only thing that actually has to be right is the random number that chose the winner — and the only way to get that right is to use the browser's cryptographic randomness source with rejection sampling, not Math.random with modulo. Once that is in place, the spin can be whatever shape you want.