Why Most "Random" Decision Wheels Aren't Actually Random

The randomness people rarely check

Decision wheels are everywhere — picking a restaurant, deciding who does the dishes, choosing a movie for group night. Most of them look identical: a colorful wheel, a spin animation, a pointer landing on a slice. What's invisible is the actual source of randomness underneath, and for a lot of these tools, that source is Math.random() — JavaScript's built-in pseudo-random function.

Why Math.random() isn't the right tool for a fair pick

Math.random() is designed for things like animations, games, and visual variety — cases where "good enough" randomness is fine and nobody's checking for bias. It is explicitly not designed to be cryptographically secure or provably uniform, and different JavaScript engines implement it differently under the hood. For picking which movie to watch, the practical difference is negligible. But if you actually care about a pick being unbiased — splitting a genuinely 50/50 decision, running an elimination draw, or anything where fairness matters to the people involved — it's worth using a generator that's actually built for that purpose.

What crypto.getRandomValues() does differently

The Web Crypto API's crypto.getRandomValues() is designed for cryptographic use cases — generating keys, tokens, nonces — which means it has to meet a much higher bar for statistical randomness and unpredictability than a general-purpose function like Math.random(). Using it to pick the winning slice on a decision wheel is arguably overkill for casual use, but it means the pick is genuinely as fair as the number of options allows, with no shortcuts.

Avoiding modulo bias

Even with a good random source, a common mistake is taking a random 32-bit integer and using % n to squeeze it into a range of n options. If n doesn't evenly divide the range of possible values, some options end up very slightly more likely than others — a subtle bias called modulo bias. The fix is to reject and re-roll any value that falls in the leftover, unevenly-divisible range, guaranteeing every option has exactly equal odds regardless of how many options you enter.

Why the animation doesn't need to be "real"

Here's the part that surprises people: the visual spin — how many rotations, the easing curve, how long it takes to slow down — doesn't need to be random or fair at all. The outcome is already decided the instant you click spin, using the secure random pick. The animation is just theater layered on top, calculated afterward to land the wheel visually on whichever option was already chosen. Separating "what's fair" from "what looks good" lets both be optimized independently.

Elimination-style decisions

For situations like a chore rotation or narrowing down a shortlist, removing an option after it's picked turns a single spin into a fair random ordering — useful for anything where you need to work through a list rather than just pick one thing.

What to look for

• Does the tool mention what random source it actually uses?
• Is the pick decided before or after the animation plays?
• Does it avoid modulo bias when converting randomness into a slice index?
• Is there a history log so you can check the results aren't suspiciously repetitive?

A decision wheel that gets these details right isn't just for show — it means "let the wheel decide" is an answer everyone in the room can actually trust.