Home/Calculators/Random number generator
CalculatorRandom Number Generator
Draws numbers from a range you set, one at a time or in bulk, with an option to allow or forbid repeats. Uses the browser's cryptographic random source with rejection sampling, not a naive modulo, so the results aren't quietly skewed toward the low end.
Result
—
Not for lotteries, prize draws, or security tokens/keys. This is a general-purpose picker for everyday use (sampling, games, picking a name). It is not audited, certified or suitable for anything with legal, financial or cryptographic stakes.
crypto.getRandomValues vs Math.random
Math.random() is a non-cryptographic pseudorandom generator — fast, fine for animations or shuffling a quiz, but its internal state can in principle be inferred from enough outputs, and browsers make no guarantee about its statistical quality. crypto.getRandomValues() draws from the operating system's cryptographically secure random source (the same kind used for session tokens and encryption keys) and gives no such foothold. This tool uses crypto.getRandomValues throughout, not because picking a number from 1–100 needs cryptographic security, but because it removes an entire category of "was that actually random" doubt for free.
Modulo bias, and why this tool doesn't use it
A common shortcut for "random number from 0 to N−1" is rawValue % N. That works cleanly only when N evenly divides the generator's output range. When it doesn't, the leftover remainder skews toward the low end of the range, because the low numbers get one extra chance to appear from the "overflow" values at the top of the raw range.
| Raw byte range | Count of values | Maps to |
|---|---|---|
| 0–99 | 100 | 0–99 (one full pass) |
| 100–199 | 100 | 0–99 (a second full pass) |
| 200–255 | 56 | 0–55 only (a partial third pass) |
Values 0–55 end up reachable by three different raw bytes each, while 56–99 are reachable by only two — so the low half of the range is measurably more likely to appear. The bias is small here but grows sharply for small ranges relative to the raw byte range, and it is entirely avoidable.
Rejection sampling fixes this: work out the largest multiple of the range that fits inside the raw output space, and if a drawn value falls above that cutoff, throw it away and draw again. Every value that survives has exactly the same number of raw values that could have produced it, so the result is unbiased. This tool implements exactly that — draw a 32-bit unsigned value from crypto.getRandomValues, reject and redraw anything at or beyond the largest clean multiple of the requested range, and only then map what's left into your min–max window.
Questions people ask
Can I use this to pick lottery numbers?
You can, but you shouldn't rely on it for anything with money or legal weight riding on it. This tool is not certified, audited or logged, and official draws use regulated, independently verified equipment for good reason.
Can I use this to generate a password or API key?
No. Even though the underlying randomness source is cryptographically secure, this tool formats output as decimal numbers in a range you choose, not as a password-strength string, and it makes no guarantee about output handling (clipboard history, browser extensions) that a dedicated secrets tool would control for. Use a password manager for that.
What happens if I ask for more unique numbers than fit in the range?
The tool shows an error instead of a truncated or duplicated list. If your range is 1–10 and you ask for 15 unique numbers, there are only 10 possible values, so 15 unique draws are mathematically impossible.
Why does the same range sometimes take a moment longer to generate?
Rejection sampling occasionally throws away a drawn value and redraws — usually once in a while, very rarely more. It's imperceptible at normal counts and is the cost of removing modulo bias rather than a bug.