The moment a spin actually matters — a raffle prize, who presents first, which student gets called on — someone will eventually ask “but is it really random?” That’s a fair question, and “trust me” isn’t a satisfying answer to it. Here’s the actual mechanism, in plain terms, so you can answer it properly instead of just asserting it.
The number generator matters more than people assume
Most random-looking behavior in software, including plenty of other spinner wheels, comes from Math.random() — a fast, general-purpose function built into every browser. It’s genuinely fine for things like shuffling a UI animation or picking a placeholder color. It was never designed to resist someone trying to predict or influence it, and it isn’t intended for anything where an outcome has real stakes attached.
This wheel doesn’t use it. Every spin’s outcome comes from crypto.getRandomValues() — the Web Crypto API’s cryptographically secure random source, the same category of randomness browsers use for generating encryption keys. It draws from the operating system’s own entropy sources rather than a predictable internal formula, which is the actual technical distinction between “looks random” and “is random” in a way that holds up to scrutiny.
Concretely: the wheel asks the browser for a 32-bit random integer, then divides it down to a fraction between 0 and 1. That fraction is the one and only piece of randomness behind every spin’s result.
How that one random number becomes a winner
What happens next depends on which of the two spin modes is active, though both are built on the exact same random draw.
Normal mode picks the winner first, before the wheel even starts moving. The random fraction gets multiplied against the total weight of all entries, and whichever entry’s slice that number falls into is the winner — the spin animation is then calculated backward to land there. This is a direct, one-step selection: no repeated sampling, no rerolling if the “wrong” entry comes up.
Natural End mode (the default) works in the opposite order. The random fraction picks how far the wheel spins, not who wins — the wheel spins that exact amount, and only once it’s actually stopped does the code check which segment ended up under the pointer. Nobody, including the app itself, knows the winner until the wheel has physically stopped. If you want the strongest possible answer to “was this decided in advance,” this is it — there’s no winner variable set anywhere before the wheel finishes moving.
Weighted entries don’t change any of this
Giving an entry a bigger slice doesn’t touch the randomness at all — it changes how much of the 0-to-1 range that entry occupies. An entry weighted to take up 25% of the total gets a wider slice, and a wider slice means the same uniformly random draw lands inside it roughly a quarter of the time. The random number generation is identical either way; only the size of the target each entry represents changes. That’s also why Natural End mode doesn’t need any separate weighted-selection logic — a bigger slice is simply more likely to be wherever the wheel happens to stop, automatically.
What this doesn’t (and can’t) protect against
Being cryptographically random settles the “is the number generator rigged” question, but it doesn’t settle every fairness question people actually care about. If someone enters a name multiple times, that name has more chances — not because the draw is biased, but because it has more tickets in the hat. If entries are weighted and nobody said so beforehand, that’s a real fairness problem, just not a randomness one. The generator can only be as fair as the list you gave it; make sure that part is right, and the number behind the spin already is.
Don’t just take this explanation on faith — our randomness audit page runs this exact code live in your browser, thousands of times over, so you can see the actual results for yourself.