Random Name and Item Picker

The shuffle almost everyone writes is broken

Search for how to shuffle a list in JavaScript and the first answer is usually one line: sort the array with a comparator that returns a random number. It is short, it looks clever, and it does not produce a random order.

A sorting algorithm assumes the comparator is consistent — that if it is told A comes before B, that stays true. Hand it a coin flip instead and the result depends entirely on which pairs that particular algorithm happens to compare, and in what order. The outcome is not uniform, and the bias is not subtle: items tend to finish close to where they started, and the pattern changes between browsers because their sort implementations differ.

The correct algorithm is Fisher-Yates, and it is no harder. Walk the list from the last position backwards. At each step, pick a random position at or before the current one and swap the two items. Every one of the possible orderings comes out equally likely, it touches each item once, and it is what runs when you press Shuffle above.

Where the randomness comes from

Math.random() is a pseudorandom generator: a fixed formula, seeded once, producing a stream that looks random and is completely determined by that seed. It is fast and perfectly good for jitter in an animation. It is also not designed to be unpredictable — given enough consecutive outputs, its internal state can be reconstructed and the next values worked out.

This tool uses crypto.getRandomValues() instead, which draws from the operating system's cryptographic random source, the same one used to generate encryption keys. For picking who buys coffee this is overkill. For a draw where someone stands to win something, it removes an entire class of argument, and it costs nothing.

The modulo trap

Getting a random number between 0 and 4 billion is easy; turning it into a number between 0 and 9 is where people slip. The obvious move is to take the remainder after dividing by 10. But 2^32 is not a multiple of 10, so the leftover chunk at the top of the range makes the first few results marginally more likely than the rest. At these list sizes the effect is far too small to ever notice. The fix is still worth applying: discard any value that lands in the incomplete final block and draw again. That is one extra draw in vanishingly rare cases, in exchange for a distribution that is exactly even rather than nearly even.

Random does not look random

Pick one name from twenty, put it back, pick again, and there is a one in twenty chance of the same name twice. People read that as broken. It is the opposite: a generator that refused to repeat itself would be the biased one. If you need several different winners, either raise "how many to pick" — a single draw always returns different entries — or switch on "delete winners from the list" and run the rounds one at a time.

The same instinct produces the gambler's fallacy in the office raffle. Nobody is "due". Each draw knows nothing about the last one, and the only way to give someone better odds is to put them in the list more than once, which is also the only weighting this tool supports. Two lines with the same name gets you double the chance — just remember to untick "ignore duplicate lines" first, since that option exists to clean up pasted data.

Splitting into teams

Teams mode shuffles the whole list, then deals the entries out one at a time like cards. That keeps the groups within one member of each other even when the list does not divide evenly, and it means the leftover people are randomly chosen rather than always being whoever was at the bottom of the list. It is random, not balanced: the tool knows nothing about skill, seniority or who cannot be in a group with whom.

What it cannot do for you

• Prove anything to a sceptic. There is no seed to publish, no timestamp, no log and no receipt. The result exists only on your screen. For a public giveaway with real prizes, run the draw on a recorded call or use a service that stores the entry list and the outcome — not because this is less fair, but because fairness you cannot demonstrate is not worth much in an argument.
• Read structured data. Lines are entries. A pasted CSV row becomes one entry, commas included, not one entry per cell.
• Show enormous lists. The result stops after 500 rows and tells you how many it left out. The draw itself still covers the whole list.
• Remember anything. Reload the page and the list is gone, along with who has already won. Copy the result out before you close the tab.

Frequently asked questions

Is it actually random?

It uses crypto.getRandomValues(), your browser’s cryptographic random source, combined with a Fisher-Yates shuffle and rejection sampling so no entry is even slightly favoured. That is a stronger guarantee than most picker sites, which use Math.random() and a sort-based shuffle.

Can the same name come up twice?

Not within one draw — asking for three picks gives three different entries. Across separate draws it certainly can, because each draw starts fresh. Tick "delete winners from the list" to run multiple rounds without repeats.

Can I make one entry more likely to win?

Only by listing it more than once, and you will need to untick "ignore duplicate lines" for that to count. There is no weight or percentage field, which is a deliberate limit rather than an oversight.

Does my list get uploaded anywhere?

No. The page makes no network requests after it loads, the draw runs in your tab, and nothing is stored. Reloading the page wipes the list, so copy anything you need to keep.

Can I use this for a prize giveaway?

The draw is fair, but it produces no evidence that it was. There is no log, no seed and no timestamp, so if entrants might dispute the result, record the screen while you draw or use a service built for verifiable giveaways.

Last updated September 19, 2026