Is the wheel rigged? How to check

A wheel that spins for a few seconds and stops on a name asks you to take a lot on faith. This guide is for the person who would rather not. It lists the claims SpinThatWheel makes about its draw — every entry exactly 1/N, the pick made before the animation, no memory between spins, nothing sent anywhere — and for each one says what the mechanism is and how you can check it from your own screen. It ends with what the site does not offer, because a verification guide that stops at the good news is not one. Every number below is computed at build time by the same engine that runs the wheels. Where a draw is shown step by step, the random bytes are scripted so the example is reproducible; live spins draw from crypto.getRandomValues.

What "fair" means here

On this site, fair has one definition: a wheel of N entries gives every entry a probability of exactly 1/N on every spin. Not approximately, not "close enough after enough spins" — exactly, by construction of the draw. The engine divides the circle into N equal segments of 360/N degrees in list order, and the pick is an index chosen uniformly from 0 to N−1.

Three preset wheels make the arithmetic concrete. The Coin Flip Wheel has 2 segments of 180° each, so each face wins with probability 50.00%. The Dice Wheel has 6 segments of 60°, each face at 16.67%. The Wheel of US States has 50 segments of 7.2°, each state at 2.00%. Those figures come from running the engine's segment geometry on the actual preset lists during the build — this page cannot show a different N than the wheel uses.

The common misreading is to judge fairness by the picture. But the geometry exists for the eyes only. The winner is chosen by index first, and the wheel is then rotated so that segment's midpoint lands under the pointer. At the 100-entry cap each segment is a 3.6° sliver, and each is exactly as likely as a half-circle on the 2-entry coin — probability comes from the draw, not the drawing.

The draw happens before the wheel moves

The engine's spin function takes an entry list and a byte source, draws the winning index, and returns three things: the index, the label, and the angle the wheel must decelerate onto. All three exist before any animation begins. The roughly four-second ease-out rotation you watch is calculated backwards from that angle — it is a way of announcing a result that already exists, not a way of producing one.

Here is that function run on the dice wheel with scripted bytes 7 then 3. The first byte, 7, is at or beyond 6 and is discarded; the second, 3, is accepted and becomes index 3, which is the segment labelled "4" with its midpoint at 210°. That angle is the wheel's destination, fixed on the press. Nothing about the wheel's resting position, the timing of your click, the deceleration curve, or any previous spin enters the calculation, because none of those is an input to the function.

Why draw first rather than let the animation decide? Because a result that depends on the animation depends on everything that feeds the animation — frame timing, the resting position, the moment of the click — and none of those is a documented source of randomness. A draw made from random bytes, with the animation as presentation, has a fairness you can state in one line and test exhaustively. The full mechanism is on the methodology page; the step-by-step walk through a single spin is How the wheel picks a winner.

Checking the mapping, byte by byte

Random bytes come from crypto.getRandomValues, the browser's cryptographically secure generator. The engine maps them onto N segments by rejection sampling: it takes the minimal number of bits whose range covers N, masks away the excess top bits, and if the result is N or larger, discards it and draws again. It never takes a remainder.

Because a byte has only 256 values, this can be checked exhaustively: the build drives every byte through the mapping and counts how many are accepted on the first draw, how many are rejected, and how often each outcome is hit. It does that for this page on three wheels, and it refuses to publish the page unless every outcome's tally is equal:

Dice: 192 accepted, 64 rejected, each outcome hit 32 times.
States: 200 accepted, 56 rejected, each state hit 4 times.
Coin: no byte rejected — the engine keeps 1 bit — and each face hit 128 times.

Equal tallies over every possible input is what "exactly 1/N" means in practice, and it is a property of the mapping, not of luck.

Masking is what keeps the rejected share small. For the dice wheel the engine keeps 3 bits, so a byte of 250 is masked down to 2 and accepted as the segment labelled "3" — the high bits are discarded, not folded in. Only candidates from 6 up to 7 trigger a redraw, which is why redraws are rare and spins stay instant.

Compare the shortcut the engine refuses. If the same 256 bytes were reduced modulo 6 instead, the first 4 of the 6 outcomes would each be hit 43 times and the remaining 2 only 42 times — a tilt toward low-numbered segments that no amount of spinning would smooth out, because it is built into the arithmetic. Rejection sampling redraws instead, and the tallies come out equal.

No memory between spins

Each spin is an independent draw. The spin function receives the entry list and a byte source and nothing else — there is no argument for the previous result, the spin count, or a streak, so there is nothing a streak could act on. The history panel on a wheel page is a display of past results; the engine never reads it.

Independence also produces streaks, so it helps to know what to expect. On the coin wheel each face is 50.00% on every spin, and because each spin is an independent draw, the probability of five heads in a row is 3.13% — about 1 in 32 — uncommon on any single try, and bound to turn up across many. After five heads, the sixth spin is still 50.00% heads. A wheel that "corrected" for a streak would be the rigged one: it would be reading its own history and steering.

Eliminator mode is the one case where something does carry from spin to spin. Each spin removes the picked entry from the list; the next spin is a fresh uniform draw over the entries that remain — 1/N, then 1/(N−1), and so on. What changes is the list, not the draw. Here is a run on a 4-entry list (Kettle, Lamp, Mirror, Rug) with scripted bytes 2, 3, 0, 1: the first spin, at 25.00% per entry, removes Mirror; the second, at 33.33%, removes Kettle; the third, at 50.00%, removes Rug; and Lamp is the survivor. Spin 2 asked for 2 bytes because the scripted byte 3 produced a candidate at or beyond the shrinking span of 3 and was rejected; the byte 0 that followed was accepted — the redraw rule holds at every step. Every entry started with the same 1/N chance of surviving, and editing the list mid-elimination restarts it.

Check one: reduced motion

Switch on your system's reduced-motion preference, then spin. The animation is skipped entirely and the identical draw is announced immediately. This demonstrates directly that the spinning was never the deciding part: with the presentation removed, the result still arrives, produced by the same function from the same bytes. If the animation were doing the choosing, there would be nothing to announce.

Check two: the network tab

Open your browser's network tab, spin a few times, edit the list, and spin again. No request carries your entries, and no request is made to fetch a result: the draw happens in the page, from bytes generated in the page. A wheel taking instructions from a server would have to talk to one.

Your list is saved in your browser's local storage so it survives a reload — on your device, removable with the Reset button or by clearing site data. Spins, results, and history exist only on the page and die with the tab. The one path a list can take off your machine is a share link you copy yourself, and even that is built to stay local: the entries are percent-encoded into a #items= fragment, and browsers do not include fragments in web requests. The coin wheel's share link, built by the engine, is https://spinthatwheel.net/coin-flip-wheel/#items=Heads|Tails — 11 characters after the equals sign, none of which are sent when the link is opened.

What this site does not offer

Verification has limits, and they should be stated as plainly as the claims. The randomness is cryptographically strong, but the site is not a certified gambling or raffle system. There is no auditor. There is no seed escrow — no published seed you could use to replay a spin later and prove what it produced; the result exists on the page and nowhere else. And there is no protection against the operator of a screen simply re-spinning until they like the result: the engine cannot tell a first spin from a tenth.

Those limits follow from the design that makes the other checks possible: a draw that happens entirely in your browser, with nothing sent anywhere, is one no outside party can log or attest to. For casual fairness among people who trust each other's screens, that trade is the right one. For money-staked drawings it is the wrong tool, and this site says so rather than sell it. It is not a gambling device, not a certified raffle system, and not a substitute for professional judgment.

Frequently asked questions

The same entry won three times in a row. Is the wheel rigged?

No. Each spin is an independent draw with every entry at exactly 1/N, and the engine has no input for previous results. On the 6-face dice wheel, the probability that whichever face wins the first spin also wins the next two is 2.78% — uncommon on a single attempt, expected now and then across many. A wheel that prevented streaks would be the one steering the outcome.

Does the moment I click matter?

No. The bytes are drawn from the browser’s cryptographically secure generator at the press, and the draw uses only those bytes and the entry list. The wheel’s resting position, the deceleration curve, and the timing of the click are not inputs to the function that picks the winner.

Can the site see my list or push a result to me?

No request carries your entries and no request fetches a result — you can confirm both in your browser’s network tab. The list lives in your browser’s local storage, spins and history die with the tab, and share links carry the list in a fragment that browsers do not include in web requests.

What does a rejected draw look like from the outside?

Nothing. A rejected candidate is discarded and redrawn inside the same press, before anything is shown. In the dice example on this page, the byte 7 was rejected and 3 accepted, and the only visible result is the segment labelled "4". Masking keeps the rejected share small — 64 of 256 bytes on the dice wheel — so redraws are rare and spins stay instant.

Can I prove afterwards what a spin produced?

Not to a third party. There is no seed escrow and no server log; the result exists on the page, in the history panel, and dies with the tab. That is the honest limit of a draw that never leaves your browser.

Are the tiny segments on a big wheel less likely to win?

No. At the 100-entry cap every segment is a 3.6° sliver, and each one wins with exactly the same probability as any other, because the index is chosen from random bytes before any geometry is involved. The wheel is rotated to the winner; the winner is not read off the wheel.

Checkable, not certified: the wheel decides fairly and you can verify the mechanism yourself, but it cannot know your situation — do not delegate consequential decisions to it. Everything runs locally in your browser; see the methodology page for how the draw works.