Browser randomness and fair selection: numbers, dice, and wheels

A random number generator is appropriate when every outcome is an integer in a known range, when you need several draws, or when the familiar model is a die with a fixed number of sides. A decision wheel is appropriate when outcomes are names, tasks, meals, teams, or other labels that participants should see before the selection.

The animation is presentation rather than the source of randomness. A well-designed wheel selects an index from the option list and then animates the chosen segment to the pointer. The visible spin can make a low-stakes group choice easier to understand without changing the probability model.

The Web Crypto API exposes crypto.getRandomValues, which fills typed arrays with values from a browser-provided cryptographically strong pseudorandom source. This is generally preferable to Math.random for security-sensitive generation and for tools that want a stronger, implementation-provided source.

The API does not create an audit log, public seed, or independently reproducible draw. A user can see the result, but another party cannot reconstruct and verify the exact entropy source from the displayed outcome alone.

Random bytes cover a fixed set of equally likely values. If that set is mapped into a range whose size does not divide it evenly, a simple remainder operation can make some outcomes slightly more likely. Rejection sampling avoids this by discarding values outside the largest evenly divisible interval and drawing again.

The same principle applies to choosing a wheel segment or die result. The source may be strong, but the final distribution depends on how the implementation converts that source into the requested number of outcomes.

Drawing with replacement allows the same number to appear again; drawing without replacement removes each selected value from the remaining pool. The requested count cannot exceed the number of available integers when duplicates are disabled. Sorting the displayed results changes presentation, not which values were drawn.

On an equal-segment wheel, every entered line receives one share. Entering the same label twice gives that label two shares even though the text looks identical. Removing a winner before the next spin creates a manual no-repeat workflow; it does not retroactively change the probability of the completed spin.

A technically uniform draw cannot correct an unfair option list. Confirm who or what is eligible, remove accidental duplicates, decide whether outcomes should be weighted, and agree on replacement rules before generating the result. For a group decision, show the finalized list before spinning.

Record the rules separately when accountability matters. A screenshot of a wheel result does not prove which options existed beforehand, whether the page was refreshed, or whether earlier unwanted outcomes were discarded.

Browser tools are suitable for games, examples, classroom activities, casual allocations, and reversible choices. They should not be presented as certified draws for regulated lotteries, financial allocation, admissions, employment, or other high-impact decisions that require governance and independent verification.

For those cases, use an approved process with documented eligibility, tamper evidence, retained inputs, independent observers or verification, and a defined dispute procedure. Strong random bytes are one component of such a system, not the whole system.