Random Number Generator

Random numbers: why the source and the bias both matter

Two easily missed technical requirements

"Random" in a program is not one thing but two: the quality of the random source, and whether the distribution is uniform. Get both right and the result is truly equiprobable; fix only one and the other can still betray you.

The source — Math.random is not enough

JavaScript's Math.random() is a pseudo-random generator. Its output is produced by deterministic arithmetic on an internal state, so once that state is deduced the whole sequence can be predicted. For games, sampling and test data that is fine; but wherever the result must not be predictable by others — a draw, an unguessable choice, a key or token — it will not do.

This tool uses crypto.getRandomValues(), the browser's cryptographic random source, fed by the operating system's entropy pool and not relying on a derivable internal state.

The distribution — modulo bias

Even with a safe source, the way you map it onto a range can introduce bias. Take "draw a random uint32 then modulo the range": if the range does not divide 2³² evenly, the first few numbers in the range get slightly more values and a higher probability.

Example: you want 1 to 3 (range size 3) and the source evenly yields 0 to 4294967295. After mod 3, the counts for 0, 1, 2 differ by one — tiny against 4 billion, but if the range is larger or the source has fewer bits (say only 8 bits for 1–3) the bias becomes statistically visible.

This tool uses rejection sampling: when a random value lands in the biased tail it is discarded and a new one drawn, until the value falls in a range that maps evenly. The cost is a few extra draws in rare cases, bought in exchange for strictly equal probabilities.

How to verify? Generate many results and tally the distribution; each value should appear about equally. Large biases show in a few thousand samples; tiny ones need more — but whether the derivation is correct can be confirmed from the implementation itself, not only by sampling.

Dedup (sampling without replacement)

Tick dedup and the same number will not repeat — statistically, sampling without replacement. The real uses are draws, shuffles and picking a few people from a list.

Removing duplicates needs a "generate a non-repeating sequence" algorithm; a common approach is to build the full candidate set then shuffle (Fisher–Yates), or keep drawing until a new value appears (which slows as the count nears the total). This tool does the latter, and explicitly checks one boundary: if the requested count exceeds the number of integers in the range (say 20 unique integers from 1–10) it is mathematically impossible, so the tool reports "count exceeds range size" instead of hanging in an infinite loop.

That check matters: without it the program freezes. It is easy to miss when writing your own draw logic.

Reproducibility

A cryptographic random source cannot be seeded — that is by design. So this tool's results are not reproducible: close and reopen the page and the same input will not yield the same output.

When you need reproducible randomness (experiments, repeatable test data, auditable sampling) use a seedable pseudo-random generator (such as the mt19937 or xorshift implementations in various languages) and record the seed. The two needs conflict: either unpredictable, or reproducible — not both.

Suitable and not suitable

The last row deserves emphasis: deciding a draw in the front end, however good the source, cannot stop a user from re-running it or editing the result directly. Draws must happen server-side with verifiable records kept.

How the tool works

Enter min, max and count (1 to 1000), optionally dedup and decimals (2 places). Click generate for one result per line, copyable at once. The range is closed — the max itself is a candidate. Generation is local, no network request.