How to Pick a Random Winner Fairly (and Prove It)
Why picking from a hat fails, what makes a random name draw actually fair, and how to run giveaway and classroom draws people don't argue with.
Everyone thinks they can pick a name at random. Close your eyes, point at the list, done. Except humans are terrible at this — we avoid the edges of lists, we drift toward names we recognize, and when we shuffle paper slips in a bowl, the last ones tossed in stay conveniently on top.
The classic cautionary tale is the 1969 US draft lottery. Capsules with birthdates went into a jar month by month, January first. They were poorly mixed, so December capsules stayed near the top and got drawn early — and men born in December were measurably more likely to be called up. Statisticians tore the method apart within weeks. The stakes of your office raffle are lower, but the failure mode is identical: a draw that looks random and isn’t.
What “fair” actually means
A fair draw gives every entry exactly the same probability. Not roughly the same. Exactly.
Software gets this wrong in two popular ways. The first is using a weak randomness source: JavaScript’s Math.random was never designed for fairness-critical use, and in older browsers its output was predictable enough that researchers reconstructed future values from past ones. The second is subtler: modulo bias. Naive code maps a random number onto a list with the % operator, and unless the list length divides evenly into the generator’s range, the first few entries come up slightly more often. The skew is small — fractions of a percent — but it’s real, it’s measurable, and for a prize draw it’s simply not necessary.
The Random Name Picker sidesteps both. It uses crypto.getRandomValues, the browser’s cryptographic generator (the one used for encryption keys), and rejection sampling instead of a bare modulo. With 10 names, each has a 1-in-10 chance. Not approximately.
Running a clean draw
Paste your list, one name per line. A few practical patterns:
- Weighted entries. Each line is a ticket. If someone earned three entries — shared the post, brought a friend, whatever your rules are — paste their name three times.
- Multiple prizes. Set the winners count to 3 and one draw returns three different names, in draw order. First name gets first prize.
- Consecutive rounds. Tick “remove winners from the list” and each winner disappears from the box after the draw. Nobody wins twice, and in a classroom, nobody gets called on twice while others hide.
One thing the tool deliberately doesn’t do: store anything. The list lives in your browser tab and dies with it. For a giveaway where participants sent personal data, that matters — you’re not uploading their names to a third-party server just to draw a winner.
The part people skip: proving it
A fair method you can’t demonstrate is worth half a fair method. Whatever you use:
Announce the mechanism before the draw, not after. “Winner picked with a random name picker on July 30” beats a vague “winners will be selected.”
Do the draw where people can see it. Screen-record the click, or run it live on a call. The whole process takes ten seconds, and a ten-second video ends every “it was rigged” thread before it starts.
Keep the input list. If someone asks why they lost, you can show exactly what went into the draw.
That’s it, really. Paste the names into the Random Name Picker, hit the button in front of your audience, and let the browser’s cryptography do what pointing at a list never could.