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. Over 1,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 a 2.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. It draws from crypto.getRandomValues, the browser's cryptographic random source, and converts those draws to a range by rejection sampling rather than by a remainder — so every entrant is exactly equally likely. The usual shortcut of taking a random byte modulo the number of entrants gives the earliest entries a small extra chance, which for ten names out of 256 byte values is about a 4 percent edge. The part that needs your care is publishing the entry list, not the draw.

What is modulo bias?

When you map a random number to a smaller range with a remainder, the range rarely divides evenly, so the first few outcomes get one extra chance each. Measured over 1.2 million draws across seven outcomes, the remainder method gave the first four outcomes a 2.8 percent edge over the rest; drawing with rejection sampling instead came out uniform. The bias is invisible in any single draw and completely real over many.

Why not shuffle with sort and Math.random?

Because array.sort with a random comparator is not a shuffle. The comparator is inconsistent — it can say a is before b and also b before a — so the outcome depends on which sorting algorithm the browser uses, and the results are measurably lopsided. This uses a Fisher-Yates shuffle, where each position is filled by one unbiased 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 tools

• Age calculatorExact age in years, months and days — worked out on the calendar rather than by dividing by 365 — with the Hijri date and the next birthday.
• BMI calculatorYour BMI on both the WHO international thresholds and the Asian cut-offs, where the risk starts lower — plus your healthy weight range in kg. Most calculators show only the first.
• Date calculatorDays between two dates with working days counted, adding and subtracting from a date, and a countdown. Month ends clamped, and a weekend you can set to Friday–Saturday.
• Time zone converterConvert a time across as many zones as you need, then read the strip that shows which hours are inside working hours for everybody — the question you actually had.
• Image compressorSmaller images without sending them anywhere — and it strips the GPS location your camera wrote into the file. Every popular compressor uploads what you give it; this one cannot.
• Password generatorReal cryptographic randomness with the bias most generators leave in taken out, and a strength figure in bits you can check rather than a coloured bar you have to believe.

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