Is the Wheel Spinner Random?

The wheel spinner is random: every spin draws a fresh number from crypto.getRandomValues, the cryptographic random source built into the browser, and that number alone decides which slice wins. The decision happens the instant you click, before the wheel starts moving, and nothing in the animation, the timing or the previous results can change it. The rest of this page shows each step and ends with a simulator so you can check the claim with your own eyes.

What happens when you click spin

Three things happen in order, and the order is the whole point. First, the browser hands over a random number and the code uses it to pick a slice. Second, the code works out a stopping angle inside that slice and adds several full turns to it. Third, the wheel animates from where it is to that angle, slowing down on a fixed curve until it stops.

1. 1The winning slice is chosen the instant you click, using the browser's cryptographic random numbers.
2. 2The wheel spins several full turns and slows down on a fixed curve toward that slice.
3. 3The pointer stops inside the slice, away from the edges, so there is never a tie.

The spin you watch is therefore a replay of a decision already made. If you could pause the animation one frame after clicking and read the variable that holds the chosen slice, it would already say which name is about to win. The wheel does not "decide as it slows down", and there is no moment during the spin where chance is still involved. Clicking again during a spin does nothing; the next draw happens only when you start the next spin.

Where the random number comes from

Browsers offer two ways to get a random number. Math.random is the everyday one, fast and fine for games, but it is a pseudo-random sequence that the browser does not promise to make unpredictable. crypto.getRandomValues is the other: it is fed from the operating system's entropy pool, the same source used to generate encryption keys and session tokens, and it is the one the wheel uses.

The code asks for one 32-bit unsigned integer, a whole number from 0 to 4,294,967,295, and divides it by 4,294,967,296. That gives a fraction from 0 up to but not including 1, with every possible value equally likely. If a very old browser had no cryptographic source at all, the code would fall back to Math.random rather than refuse to spin, but every current browser on desktop and mobile has supported crypto.getRandomValues for years, so in practice the fallback never runs.

One fraction is drawn per spin, and a second one is drawn only to choose where inside the winning slice the pointer should rest. Neither is reused, stored or sent anywhere. The simulator further down this page calls the same function, which is why its results are a fair stand-in for the real wheel.

How a random number becomes a slice

Think of the wheel as a circle of 360 degrees with the pointer fixed at the top. With eight equal entries each slice spans 45 degrees. Multiply the random fraction by 360 and you get an angle; divide that angle by 45 and round down, and you have the slice. A fraction of 0.564 becomes 203 degrees, which is slice number five, counting from the pointer clockwise.

The wheel is a circle of 360°. With 8 equal entries each slice spans 45°. The random draw is an angle, and the slice is just the angle divided by the slice size.

203° ÷ 45° = 4.51 → slice 5

Weighted entries change the slice sizes, not the method. An entry written as Pizza*3 has weight 3 and an ordinary entry has weight 1, so with Pizza and three plain entries the total is 6 and Pizza's slice covers 3 sixths of the circle, 180 degrees. The code walks through the entries adding up weights until the running total passes the random number times the total weight, and the entry it stops on is the winner. The slice drawn on the screen is sized by exactly the same arithmetic, which is why the odds you see are the odds you get. An entry with weight 0 gets no span at all and can never win, though it stays visible in the list.

Why the animation cannot change the result

Once the slice is chosen, the code picks a resting angle somewhere between 15% and 85% of the way across it, so the pointer never ends on a boundary and there is never a tie to resolve. It then adds whole turns: four for a Short spin, seven for Normal, eleven for Long. The wheel moves from its current angle to that target along an ease-out curve, fast at first and slowing steadily, and stops exactly on the target.

That curve is the same shape every time. A long spin is not "more random" than a short one; it is the same decision with more turns of decoration in front of it. The clicking sound as the pointer passes each slice edge and the confetti at the end are produced by the animation, not by the picker, and switching them off changes nothing about the odds. The same goes for wheels with more than 200 entries, where the page swaps the drawn wheel for a rolling list: the target is still chosen up front and the roll is timed to stop on it.

Can the wheel be rigged?

Only in ways you can see. The odds of this wheel are set by the list and nothing else, and the list is in a text box in front of you. If a name appears twice it has two slices. If it carries a *3 it has three slices' worth. Both are visible on the wheel as larger or repeated areas and both are visible as text. There is no setting that makes a slice win more often without changing its size, and no server involved that could substitute a result.

For a giveaway, this is the check to offer your audience: show the list, show that each name appears once with no weights, and spin in full screen. If you create a share link, the whole list is encoded in the link itself, so anyone who opens it sees the same wheel and can confirm there was nothing hidden. The random name picker is set up for exactly this, with Remove winner so a drawn name cannot be drawn twice.

Two things that are sometimes mistaken for bias are worth naming. Short runs look lumpy: eight names and ten spins will almost always leave some name unpicked and some name picked twice, and that is what randomness looks like at small numbers. And people remember the spins that fit a story, such as the same student being chosen two days in a row, and forget the hundreds that did not. The simulator below exists to replace both impressions with counts.

Test it yourself: the spin simulator

The simulator runs the real picker, the same pickWeighted function with the same cryptographic source, as many times as you choose, and skips only the animation. Each bar is one of eight equal slices and the dashed line is the count a perfectly even split would give. Try 100 spins first, then 100,000, and watch the bars tighten around the line as the numbers grow.

Spin 1,000 timesSpins1001,00010,000100,000Expected per slice: 125

–Ali

–Beatriz

–Charles

–Diya

–Eric

–Fatima

–Gabriel

–Hanna

To turn the picture into a number, the simulator runs a chi-square test. It takes each slice's count, subtracts the expected count, squares the difference, divides by the expected count, and adds the eight results together. A small total means every bar is close to the line; a large total means at least one bar is far from it. With 1,000 spins the expected count is 125 per slice, and bars anywhere from roughly 105 to 145 are ordinary.

The p-value translates that total into a question: if the wheel were perfectly fair, how often would it produce a spread at least this uneven just by luck? A p-value of 0.30 means a fair wheel does this about 30% of the time, which is nothing unusual. The verdict line uses the conventional cut-off of 0.05. At or above it, the result is consistent with a fair wheel. Below it, the spread is one a fair wheel produces less than one time in twenty, which is rare enough to deserve a second look.

Below 0.05 does not mean the wheel is biased, and this is the part people get wrong. One fair run in twenty lands there by definition, so if you press the button twenty times you should expect roughly one warning. What a biased wheel does is different: it fails again and again, and the same slice is the one sticking out each time. With eight slices the chi-square total has to climb past about 14.1 before the p-value drops under 0.05; a wheel that quietly favoured one slice by even a few percent would push past that on every 100,000-spin run and show a p-value far below 0.001.

If you prefer to check the real wheel rather than a simulator, open any wheel with a short list, set Spin time to Short, and spin it a hundred times. The Results tab keeps every outcome of the session; copy it, paste it into a spreadsheet, and count. You will see the same behaviour as the bars above: counts that wander around an even share, drift in a different direction every session, and never settle on a favourite.

The wheel spinner on the home page is the general-purpose version of everything described above, with weights, saved wheels and share links. If you only need a fair two-way call, the yes or no wheel alternates Yes and No around the wheel so the two answers always have identical odds. For drawing names where every pick must be fair and seen to be fair, the random name picker keeps a record of every result and removes winners as it goes.