Random picker

Why not Math.random

Two reasons, and only the second one really matters.

The first is that Math.random() is not designed to be unpredictable — it is fast, and nothing more is promised.crypto.getRandomValues is the browser's cryptographic source and is designed for exactly the property you want when something is being given away.

The second is the one that actually skews results, and it is not about the source at all — it is about how a random number gets squeezed into your range. The obvious way is a remainder: take a random byte, divide by the number of entrants, keep what is left over. But 256 does not divide evenly by 10, so the first six entrants get one extra chance each and the rest do not.

The bias, measured

This is not a theoretical worry, so here it is counted. Over1,200,000 draws across seven outcomes, with each outcome expected about 171,429 times:

• Remainder method — the first four outcomes averaged 173,475 and the other three averaged 168,700. That is a2.8% edge, and a chi-square of 234 against a 5% critical value of 12.59. Comfortably, measurably not fair.
• Rejection sampling, which is what this page does — a chi-square of 6.08, well inside what chance explains.

Rejection sampling is simple: draw a 32-bit number, and if it lands in the uneven tail at the top of the range, throw it away and draw again. Discarding those draws is what makes the remaining ones exactly uniform. It costs a handful of extra draws and nothing else.

And why the shuffle is not a sort

The famous one-liner arr.sort(() => Math.random() - 0.5) is not a shuffle. A sort comparator has to be consistent — if it says A comes before B, it must not later say B comes before A — and a random one is not. What you get depends on the browser's sorting algorithm, and it is measurably lopsided: items tend to stay near where they started.

This uses a Fisher-Yates shuffle: walk the list from the end, and swap each item with a uniformly chosen one at or before it. Every arrangement is equally likely, and the proof is short enough to check. Measured over 600,000 shuffles of five items, the worst deviation from an even spread across all 25 position counts was 0.51%.

If it is for a real giveaway

Fair randomness is necessary and not sufficient — the part people dispute is usually the list, not the draw. Two things worth doing regardless of which tool you use:

• Publish the entry list first, or its count, before drawing. A draw nobody can audit is a draw people are entitled to doubt.
• Record the draw. A screen recording of the list going in and the name coming out costs nothing and answers the question before it is asked.

This page cannot help with either, and no picker can. It can only promise that the arithmetic between the list and the name is not quietly favouring whoever entered first — which, as the numbers above show, is not something to take for granted.

Questions

Is it fair enough for a giveaway?

Yes — cryptographic source, rejection sampling, Fisher-Yates shuffle, and the measurements above. The part that needs your care is publishing the entry list, not the draw.

Can I draw more than one winner?

Yes. Set how many to pick; the order shown is the draw order, so first place is first.

Is my list uploaded?

No. What you paste stays in your browser. There is no account and no server in the draw.

More free tools

Password generator · Unit converter · Time zone converter · Date calculator · Age calculator

All free, all running entirely in your browser. Built by Maxverse Lab, a software studio in Karachi.