Is this wheel actually random?
Every tool on SpinPicker claims each entry has an equal chance. This page is the evidence: 16,000,000 draws, a chi-squared goodness-of-fit test for every wheel size on the site, and the code that produced the numbers.
The short answer
Yes, within what a test of this size can show. 16 of 16 wheel sizes passed at a threshold of p = 0.001, and the largest deviation any single slice showed was 2.41% away from its expected share, on the hundred slice wheel where each slice is expected only 10,000 times. A test cannot prove fairness, only fail to disprove it, and this one failed to disprove it everywhere.
How the numbers were made
For each wheel size, draw randomInt(0, n-1) the stated number of times and compare the observed slice counts to a uniform expectation with a chi-squared goodness-of-fit test. The function under test is the one the site ships (lib/random-core.mjs), imported directly rather than re-implemented.
| Entropy source | crypto.getRandomValues (Node WebCrypto, same API the browser uses) |
|---|---|
| Bias mitigation | Rejection sampling: any 32-bit draw at or above the largest exact multiple of the range below 2^32 is discarded and redrawn, so no slice inherits an extra source value. |
| Draws per wheel size | 1,000,000 |
| Total draws | 16,000,000 |
| Source code | scripts/randomness-test.mjs |
| Run on |
Results per wheel size
| Slices | Expected each | Lowest | Highest | Largest deviation | Chi-squared | df | p | Result |
|---|---|---|---|---|---|---|---|---|
| 2 | 500,000 | 499,446 | 500,554 | 0.111% | 1.23 | 1 | 0.2679 | Pass |
| 3 | 333,333.333 | 332,555 | 334,004 | 0.233% | 3.20 | 2 | 0.2017 | Pass |
| 4 | 250,000 | 249,288 | 250,616 | 0.285% | 5.51 | 3 | 0.1381 | Pass |
| 5 | 200,000 | 198,916 | 200,924 | 0.542% | 11.89 | 4 | 0.0182 | Pass |
| 6 | 166,666.667 | 166,256 | 167,091 | 0.255% | 3.57 | 5 | 0.6136 | Pass |
| 7 | 142,857.143 | 142,608 | 143,446 | 0.412% | 5.03 | 6 | 0.5403 | Pass |
| 8 | 125,000 | 124,631 | 125,415 | 0.332% | 2.69 | 7 | 0.9121 | Pass |
| 10 | 100,000 | 99,189 | 100,801 | 0.811% | 17.92 | 9 | 0.0361 | Pass |
| 12 | 83,333.333 | 82,950 | 83,943 | 0.732% | 12.74 | 11 | 0.3106 | Pass |
| 14 | 71,428.571 | 70,925 | 71,867 | 0.705% | 13.49 | 13 | 0.4107 | Pass |
| 20 | 50,000 | 49,579 | 50,401 | 0.842% | 16.25 | 19 | 0.6405 | Pass |
| 24 | 41,666.667 | 41,345 | 42,180 | 1.232% | 25.67 | 23 | 0.3167 | Pass |
| 26 | 38,461.538 | 38,103 | 38,923 | 1.200% | 37.90 | 25 | 0.0473 | Pass |
| 30 | 33,333.333 | 32,838 | 33,723 | 1.486% | 44.12 | 29 | 0.0358 | Pass |
| 50 | 20,000 | 19,711 | 20,287 | 1.445% | 53.07 | 49 | 0.3201 | Pass |
| 100 | 10,000 | 9,759 | 10,223 | 2.410% | 100.98 | 99 | 0.4257 | Pass |
What could have gone wrong, and did not
The realistic failure mode for a wheel is not a broken random number generator. It is a broken mapping onto the slices. A browser hands back a 32-bit integer, and folding that onto a range with a plain remainder is only fair for ranges that divide 232 exactly. Two, four and eight do. Three, seven, ten, twenty-six and one hundred do not, and for those the lowest-numbered slices would quietly collect a few extra outcomes on every spin, forever, in a way nobody would ever catch by eye.
That is why the sizes tested above include the awkward ones. A test that only checked coins and eight-slice wheels would pass trivially while a real bias sat in the hundred slice raffle wheel. Rejection sampling is what removes it: any draw landing in the incomplete final block of the 32-bit range is thrown away and redrawn, so every slice ends up backed by exactly the same number of source values.
Frequently asked questions
Does a chi-squared test prove the wheel is fair?
No test proves fairness; it can only fail to find bias. What this test shows is that across 16 million draws no wheel size deviated from a uniform distribution by more than chance would explain. That rules out the failure modes that actually occur in practice, in particular modulo bias on a range that does not divide evenly into 2 to the power 32.
Why does one of the p-values look low?
Under a genuinely fair generator the p-value is uniform between 0 and 1, so roughly one test in twenty lands below 0.05 purely by chance. That is the test behaving correctly. A single low p-value in one run is expected noise; a p-value that sits near zero for the same wheel size run after run would be the real signal, and that is the pattern the check mode looks for.
What is modulo bias and why does it matter here?
The browser hands back a 32-bit number. Folding that onto a range with a plain remainder is only fair when the range divides 2 to the power 32 exactly, which it does for 2, 4 and 8 but not for 3, 10, 26 or 100. Without a correction the low-numbered slices on a 100 slice wheel would come up marginally more often, forever. SpinPicker discards any draw at or above the largest exact multiple of the range and draws again, so every slice maps onto the same number of source values.
Is Math.random used anywhere?
Only as a fallback for an environment with no WebCrypto, which no browser able to run this site has. The specification does not require Math.random to be uniform or unpredictable, and implementations have historically been neither, which is why it is not the primary source.
Can I run this test myself?
Yes. It lives in scripts/randomness-test.mjs and imports the same function the site ships rather than a copy of it, so there is no gap between the code under test and the code doing the spinning. Run it with a different draw count and you get different numbers with the same conclusion.
Where this applies
One randomness primitive drives every tool on the site: the spinner wheel, the random name picker, the team generator, the dice roller, the coin flip and the number generator. Tested once, used everywhere.
Reproducing this: run node scripts/randomness-test.mjs in the repository. It writes data/randomness-report.json, which is what this page renders. No figure on this page is typed in by hand.