Is an online spinning Wheel really random?

How does Randomly pick a Winner?

Randomly first builds the eligible pool from enabled Entries. It askscrypto.getRandomValues() for an unsigned 32-bit value, accepts only values that divide evenly across the pool size, and maps the accepted remainder to one eligible position. The selected Entry is stored before the reveal starts.

1. Read the enabled Entries and exclude disabled or completed ones.
2. Request a 32-bit value from browser Web Crypto.
3. Reject a value when using it would introduce modulo bias.
4. Map the accepted value to exactly one eligible position.
5. Commit that Entry, then begin the visible reveal.

MDN describes crypto.getRandomValues() as providing cryptographically strong random values. Randomly uses that source for unpredictability, but makes a narrower claim than “perfect randomness”: the browser and operating system provide the entropy, while Randomly is responsible for mapping the returned value correctly.

Why does rejection sampling matter?

A 32-bit source has 4,294,967,296 possible values. That total is not divisible by every possible number of Entries. Taking every value modulo the pool size would therefore give a tiny extra chance to some positions. Randomly discards the short uneven tail before taking the remainder, so every accepted position has the same number of source values behind it.

With three eligible Entries, for example, the largest 32-bit value is rejected because 4,294,967,296 leaves a remainder of one when divided by three. The Tool draws again instead of assigning that extra value to the first position. This is implementation-level fairness: it prevents a mathematical mapping shortcut from favoring an index.

Is the Winner chosen before the Wheel spins?

Yes. In Randomly, “chosen before the animation” means committed, not secretly manipulated. The Tool stores the selected Entry and prevents list edits while the Selection is revealing. The Wheel then calculates a rotation that places the committed Entry at the pointer; the Race reveals the committed elimination for that round.

This separation is deliberate. Frame rate, device speed, reduced-motion preferences, fullscreen availability, or an animation delay should not decide who wins. Automated tests run standard and reduced-motion paths against the same committed outcome and verify that leaving fullscreen does not replace an in-progress Selection.

A preselected result is not automatically trustworthy in every online spinner. The useful questions are whether the method is disclosed, whether hidden weights or rerolls exist, whether the eligible list can be checked, and whether the displayed result matches the committed one.

Does random mean every short run looks balanced?

No. Equal probability does not promise an alternating or evenly spread short sequence. When repeats are allowed, the same Entry can appear twice or several times in a row without the random source being broken. Randomness describes the chance before each Selection, not a guarantee that a small history will look tidy.

Use no-repeat mode when the job is broad participation. A selected Entry becomes excluded for the current round, and Reset makes the pool eligible again. For a complete sequence, the Order Tool applies the same unbiased position mapping inside a Fisher–Yates shuffle. NIST describes a random permutation as selecting all items without replacement—the same basic job behind a repeat-free order.

Duplicate rows are separate from the repeat setting. If “Sam” appears twice, those rows occupy two eligible positions. Turning repeats off can exclude the selected Sam row while the other Sam row remains eligible. Review duplicates before starting when each distinct person or option should receive one chance.

What makes a random group process feel fair?

Technical randomness is only one layer. A group can reasonably distrust a sound generator when the roster is hidden, eligibility changes during the reveal, duplicate rows are unexplained, or the facilitator reruns every inconvenient result. A visible rule and consistent correction path make the method understandable.

1. Show the eligible Entries long enough for the group to check them.
2. Explain whether repeats are allowed and when the round resets.
3. State how absence, a pass, or a genuine setup error will be handled.
4. Do not edit the pool or start another Selection during the reveal.
5. Use Undo for the latest real mistake, not to chase a preferred result.

Read the group fairness guide for a facilitator script, or compareselection with and without replacement before choosing a repeat rule.

If the output format is still unclear, compare a Picker Wheel with the Order Tool. For a dated feature-by-feature review, read the transparent Wheel of Names alternatives comparison and verify any capability that matters on the Tool’s current official page.

What Randomly cannot prove

Randomly cannot prove that every eligible person was entered, that the activity is appropriate, that consent is freely given, or that a random outcome is safe or legally valid. It also does not provide certified lottery auditing, secret weighting, or a “rigged” mode. The operator remains responsible for the input and the consequences.

Keep the Tools to low-stakes participation, order, prompts, games, and everyday choices. Do not use them for medical, legal, financial, employment, disciplinary, safeguarding, safety, paid-entry promotion, lottery, or other regulated outcomes. Those situations require the relevant policy, qualified judgment, records, and legal controls.

Entries stay in the browser by default. Shared Setup data is carried in the URL fragment rather than the path or query, but anyone who receives the complete URL can read it. Review the privacy approach and use neutral labels instead of private information.