How Random Is the Wheel?
A convincing spin animation is not evidence of fair selection. What matters is how an entry is chosen and whether the visual result matches that choice. SpinAndDecide uses the browser’s cryptographic random-value API and rejection sampling to select an eligible ticket. The wheel animation then reveals the selected entry. This guide explains that process, what equal chance means and which limitations a browser-based tool still has.
By SpinAndDecide · Updated November 4, 2026
Selection comes before the animation
When you press Spin, the tool first reads a snapshot of the current entries and settings. It chooses a winning ticket using secure random values, then calculates an animation that finishes on the selected entry. Editing controls are locked during that animation so a changed list cannot quietly replace the list that was drawn.
The speed, number of turns, theme and sound are presentation features. They do not supply the randomness or make one label more eligible than another. A slow-looking finish can make the reveal easier to follow, but it does not improve the statistical quality of the chosen ticket. The written result is the authoritative outcome for that spin.
Why a simple remainder can introduce bias
A browser can supply a uniformly distributed unsigned 32-bit value from zero through 4,294,967,295. Suppose the wheel needs one of six tickets. Dividing that value into six possible remainders is tempting, but the size of the 32-bit range is not an exact multiple of six. Some remainders would occur one more time than others if every possible source value were accepted.
That difference is very small, but it is avoidable. The tool calculates the largest multiple of the ticket count that fits within the source range. Values outside that accepted interval are discarded and drawn again. Applying the remainder only after that rejection makes every ticket correspond to the same number of accepted source values.
What equal chance actually applies to
In ordinary mode, every nonblank entry line has weight one. With ten entries, each has a one-in-ten chance. Label length, alphabetic order and decorative colors do not change that allocation. Duplicate labels remain separate entries because the tool cannot assume whether you intended multiple tickets or made a typing mistake.
Equal entries are not always equal people or outcomes. If one person owns three of ten tickets, that person has three chances out of ten. If two differently worded labels both mean pizza, pizza has more collective representation than one soup label. Fairness starts with a list that correctly represents the eligibility rule you announced.
How weighted mode changes the model
Weighted mode assigns a positive integer to every entry. The random ticket is drawn uniformly from the sum of those weights, and cumulative weight ranges map that ticket to a label. Weights two, one and one produce probabilities one half, one quarter and one quarter. Larger segments reflect larger weights on the live wheel.
This is intentional unequal probability, rather than bias accidentally introduced by an algorithm. Participants should know when weights are used. The tool accepts weights from one to one thousand per entry, with at most one thousand entries, keeping the total well within the supported random-integer range. A weight is a probability input, not a quota or inventory count.
Why repeated results are normal
Independent draws do not remember that an entry has recently won. A six-sided die can produce six twice in succession, and a yes/no wheel can show several Yes results in a row. With the original list unchanged, a previous outcome does not make its opposite due.
Winner removal creates a different process: selection without replacement. After an entry leaves, the remaining list is smaller and the remaining probabilities are recalculated. That is useful for drawing unique names, but it no longer models independent dice rolls. Decide which process fits your activity before interpreting a sequence of outcomes.
Security and evidence have different limits
The browser’s cryptographic generator is a stronger source for this job than a home-made timing trick or a predictable seeded sequence. If the required API is unavailable, this tool reports an error rather than silently falling back to weaker randomness. Team allocation uses secure random integers in Fisher–Yates swaps before distributing entries across groups.
Even so, browser code is inspectable and can be modified by the person controlling the device. This site does not provide an independent observer, certified draw record or tamper-evident audit log. Do not confuse a sound selection algorithm with proof that an external event used an unmodified list or followed its rules. Use appropriate oversight for promotions or events requiring formal verification.
Technical reference: MDN documentation for crypto.getRandomValues.
Frequently asked questions
Does the wheel use Math.random to choose winners?
No. Selection uses crypto.getRandomValues with rejection sampling. Animation timing is separate from the ticket draw and does not determine which entry wins.
Does rejection sampling discard unpopular results?
No. It rejects source integers in a small leftover interval before mapping them to any ticket. It does not inspect labels, previous winners or the popularity of an outcome.
Does a long losing streak increase my next chance?
Not during independent draws from an unchanged list. Your chance changes only if the eligible entries or weights change. Removal can change the list, but a streak by itself does not.
Is the wheel independently certified?
No. The implementation can be inspected, but this site offers no independent certification or tamper-evident draw history. Those are separate capabilities from generating unbiased ticket selections.