How random are these pickers?
Every result on this site is decided inside your browser, using the same random number generator your browser uses for cryptography. Here is exactly how, and why the difference matters.
Where the randomness comes from
When you press a button on this site, the tool calls crypto.getRandomValues() — the browser’s interface to your operating system’s cryptographically secure random number generator.
On a phone or laptop, that source is seeded from genuine physical unpredictability: timing jitter between hardware events, electrical noise, and on most modern processors a dedicated on-chip generator. It is the same source that produces the keys protecting your banking session. It is not a pattern that can be predicted from previous results, and it is not something this page can influence.
Most free random pickers use Math.random() instead. It is fast and perfectly adequate for shuffling a music playlist. It is also a deterministic algorithm running from a seed, it was never designed to resist prediction, and its output quality varied noticeably between browsers for years. For a coin flip, nobody would notice. For a weekly giveaway with a few hundred entrants, “nobody would notice” is not the standard you want.
The arithmetic mistake almost everyone makes
Getting a good random number is the easy half. Turning it into a fair choice from your list is where most implementations quietly go wrong.
The obvious approach is to take a large random number and divide it by the number of options, then use the remainder. Seven options, so take the remainder after dividing by seven. This looks correct and is not, because the range of possible random values almost never divides evenly by the number of options. The leftovers all land on the first few items.
Here is the effect at a small scale. Imagine a random source that produces a number from 0 to 9, and three options:
| Option | Random values that select it | Chance |
|---|---|---|
| First | 0, 3, 6, 9 | 40% |
| Second | 1, 4, 7 | 30% |
| Third | 2, 5, 8 | 30% |
With a real 32-bit random number and a short list, the distortion is far smaller — a fraction of a percent. But it never disappears, it always favours the same end of the list, and it compounds every single time you draw. Run a 300-entrant giveaway every week for a year and the names near the top of your list have had a real, measurable advantage over the names at the bottom.
These tools use rejection sampling instead. Any random value that falls in that uneven leftover region is thrown away and a fresh one is drawn. In the example above, values 9 would simply be discarded and re-rolled, leaving three options with exactly a third each. It costs a fraction of a microsecond and it makes the odds exactly equal — not approximately equal.
Shuffling is a separate problem
The team generator and the order generator do not pick one item; they rearrange every item. That needs a different algorithm, and it has its own famous trap.
The tempting shortcut is to give each item a random number and sort the list by it. This is one line of code, and it does not produce an even spread — the bias depends on the sorting algorithm underneath, which is why the same trick gives visibly lopsided results in some browsers and not others.
These tools use a Fisher–Yates shuffle: walk the list from the end, and for each position swap in an item chosen with an unbiased draw from the ones not yet placed. Every possible arrangement of your list is equally likely. For teams, the shuffled list is then dealt out one name at a time like playing cards, so team sizes never differ by more than one person, and which team gets the extra person is itself random.
Nothing is sent anywhere
There is no server involved in a result. When you press a button, no request leaves your device — the list, the draw and the result all happen in the tab you are looking at.
This has three consequences worth knowing about:
- The tools keep working if your connection drops after the page has loaded.
- Your list cannot be logged, sold, leaked or handed over, because it never arrives anywhere it could be stored.
- Saved lists live in your own browser’s storage, on that one device. They do not sync, and clearing your browser data deletes them.
You do not have to take this on trust. Open your browser’s developer tools, switch to the Network tab, and use any tool on this site. You will see the page load, and then nothing.
Proving a draw actually happened that way
Fairness inside the tool is one problem. Convincing an audience is a different one, and it is the reason the winner picker can produce a draw record.
The record contains the time of the draw, the number of entries, the winners, and a SHA-256 fingerprint of the exact entry list. A fingerprint is a short string derived from the full text of your entries; change one character anywhere in the list and the fingerprint changes completely and unpredictably.
Used properly, it works like this:
- Close entries and generate the fingerprint of your final list.
- Publish the fingerprint before you draw.
- Draw, then publish the winners and the full entry list.
- Anyone can now re-derive the fingerprint from the published list and confirm it matches what you posted earlier.
That does not prove the winner was chosen randomly — nothing can prove that from the outside. It proves something almost as useful: that the pool was not edited after entries closed, which is the part people actually suspect.
What this does not claim
The randomness here is unbiased and unpredictable, which is what fairness requires. It is not certified, and no free browser tool can honestly claim to be, for a simple reason: you cannot audit code you did not run. Any website can describe a method and ship something else.
What you can do here is read it. The code is short, unminified and deliberately readable — open your browser’s developer tools and look at the file. The core is a few dozen lines: the rejection-sampling draw, the Fisher–Yates shuffle, and the weighted selection.
For draws where money or a legal obligation is involved, use a service that issues a signed, independently verified record of the draw, or have the draw witnessed by someone with no stake in the outcome. These tools are built for the enormous number of decisions that need to be fair but do not need a notary.
Read further
- MDN:
Crypto.getRandomValues()— the browser interface these tools call. - Wikipedia: cryptographically secure random number generators — why the distinction from ordinary pseudo-randomness matters.
- Wikipedia: the Fisher–Yates shuffle — including the common implementation mistakes.