Random Name Picker

What makes a draw defensible

The reason to use a tool for this rather than picking a name yourself is not that you cannot be trusted. It is that afterwards you want to be able to say the result was not chosen, and that claim has to survive somebody who would like it not to.

A draw made with Math.random does not survive it. The generator behind it in V8 is an xorshift with 128 bits of state, and there is published work showing that state can be recovered from a short run of outputs and the sequence then run both forwards and backwards. Anybody who watched a few earlier draws had, in principle, enough to predict the next one. Nobody is going to do that for a mug, and that is not the point: the point is that the sentence 'the result was unpredictable' is false, and you would rather it were true.

crypto.getRandomValues draws from the operating system's entropy pool, the same source used to generate encryption keys. There is no state to recover and no sequence to extrapolate. It costs nothing extra and it removes the argument entirely, which is why everything on this page uses it.

The shuffle that is not uniform

Putting a list in random order looks like the easiest thing here and contains the subtlest bug in it. The version people write from memory walks the list forwards and swaps each item with an item at any random position. It produces something thoroughly mixed up, and it is not uniform.

The arithmetic is short. For a list of n items that method makes n independent choices from n positions, so it can follow n to the power n equally likely paths. But there are only n factorial possible orderings. For n of 3 that is 27 paths over 6 orderings, and 27 does not divide by 6, so some orderings are reachable by more paths than others and come up more often. The bias is real, measurable, and invisible without measuring.

The correct version, Fisher-Yates walked backwards, swaps each position only with one at or below it, making exactly n factorial paths for n factorial outcomes. It was checked here by shuffling a four-item list a quarter of a million times and confirming all 24 orderings came up in the right proportion.

Duplicates, teams, and the small decisions

Repeated lines are kept rather than merged. Somebody who bought three raffle tickets should have three chances, and a tool that silently collapsed their entries would change the odds without saying so. If you want them merged, that is a decision to make before pasting rather than one for the tool to make on your behalf.

Teams are dealt round-robin from a shuffled list rather than cut into blocks. Both produce the same team sizes, so the difference looks cosmetic. It is not: slicing eleven people into three teams always shorts the last team, so the same position in the list is always the one that ends up in the small group. Dealing puts the remainder somewhere different each time.

Drawing several prizes is offered as an option rather than assumed, because both behaviours are correct for different events. A raffle with three prizes usually wants each name to win once. A prize draw where every entry stands for every prize does not.

There is no seed, and that is the feature

Some tools let you fix a seed so a draw can be reproduced. That is genuinely valuable for testing, for simulation, and for reproducible research. It is precisely wrong for a prize draw, because a reproducible draw is one that could have been run repeatedly until it gave an answer somebody liked.

There is no seed here and no way to recover a previous draw. If you need to prove a draw was fair rather than merely assert it, the established approach is to commit to a seed publicly before the draw, by publishing its hash, and reveal it afterwards. That establishes something. A replay button does not.