How a genuinely random number gets drawn
Two different things both get called "random" in software. Math.random, the everyday version built into every browser, is a pseudo-random generator: fast and statistically well spread, fine for a shuffle animation, but not built to resist someone working backwards from a run of outputs to guess what comes next, and in several browser engines its internal state genuinely can be recovered that way. This tool draws every number with crypto.getRandomValues, the Web Crypto API's cryptographic generator instead, the same source this site's password generator draws its characters from, built so that outputs give no usable clue about anything else it will ever produce.
A second, quieter problem shows up once a raw random value has to be squeezed into a chosen range. The obvious approach, reduce it modulo the size of the range, very slightly favours the low end of that range whenever the range size does not divide evenly into the generator's own output space. Rejection sampling avoids that: draw a value, and if it falls in the small leftover remainder that would otherwise cause the bias, throw it away and draw again. What survives maps onto the range with exactly equal probability, not just approximately equal.
Why "number modulo range size" quietly cheats low numbers
Say a generator produces a whole number from 0 to 9 inclusive, ten equally likely outcomes, and a range of 1 to 3 is wanted. Taking each output modulo 3 gives 0 four times but 1 and 2 only three times each. That gap looks trivial over ten outputs, but a real generator's output space is 232 values wide, and whenever the range size does not divide 232 exactly, the same lopsided pattern appears, just spread too thin to see across a handful of draws. Rejection sampling removes it outright: this tool finds the largest multiple of the range size that fits inside 232, and any draw landing above that cut-off is discarded and redrawn, so every remaining value maps onto the range with identical odds, standard practice in unbiased random-integer generation, described in, among other places, Daniel Lemire's widely cited paper on generating random integers in an interval without bias.
Why "random" often looks clumpy, not spread out
Genuinely random draws cluster far more than most people expect. Flip a fair coin 20 times and a run of four or five heads in a row turns up more often than not; roll a die repeatedly and the same number sometimes lands twice or three times in quick succession purely by chance. The mind reads a long streak as suspicious, a sign the process must be rigged or "due" a change, a pattern psychologists call the gambler's fallacy: a false belief that a run of one outcome makes the opposite outcome more likely next time. It does not. Each draw here is independent of every draw before it, the numbers have no memory, and a die that has just shown three sixes in a row is exactly as likely to show a fourth as it was on the first roll.
Unique draws and the partial Fisher-Yates shuffle
Switching on "only unique numbers" changes the drawing method, because once a value has been drawn it has to leave the pool for every draw after it. This tool uses a partial Fisher-Yates shuffle: picture every possible value lined up in an array, run the standard Fisher-Yates shuffle (swap the current position with a randomly chosen position at or after it, then move on), but stop after exactly as many swaps as numbers requested, rather than shuffling the whole array. The first however-many positions after that partial shuffle are the unique draw, each one exactly as likely as any other value in what remained, and the technique never has to build the whole array in memory, so drawing 500 unique numbers out of a hundred-thousand-wide range costs the same handful of swaps as out of a million-wide one. Fisher-Yates dates to a 1938 statistics book by Ronald Fisher and Frank Yates, turned into this efficient in-place version by Richard Durstenfeld in 1964 and set out in the form still used today in Donald Knuth's The Art of Computer Programming.
Because unique draws come from a shrinking pool, there is a hard ceiling on how many are possible: with decimals at 0, a range from 1 to 20 only contains 20 distinct whole numbers, so asking for 30 unique draws cannot be honoured. This tool caps the count at whatever the range actually holds and says so plainly, rather than silently returning fewer numbers than asked for or, worse, quietly allowing a repeat.
Decimal places: still uniform, just measured more finely
Left at 0, only whole numbers are drawn. Raise it and the tool works in a finer grid instead: at 2 decimal places, a range of 1 to 10 is really a pool of 901 equally spaced values, 1.00, 1.01 and onward up to 10.00, and one of those 901 is picked with the same unbiased method used for whole numbers, then divided back down to show the decimal figure. Adding decimal places changes how finely the range is sliced, not how fairly it is drawn from.
Using this for a raffle or prize draw fairly
For a raffle where every ticket needs an equal, one-time chance, switch unique draws on, set the range to the ticket numbers exactly (1 to however many were sold) and draw exactly as many winners as prizes on offer. Publish the range and count drawn alongside the winning numbers, "5 winners drawn, unique, from tickets 1 to 240", so anyone can check the draw matched the actual field of entries. That one sentence usually turns a private button click into something entrants can verify for themselves.
Why there is no seed to set
Some random-number tools let you type in a "seed" so a sequence can be reproduced later. This one deliberately does not: a seed only reproduces a sequence because it turns a random-looking process into a pseudo-random one with a known starting point, and the whole point of cryptographic randomness here is that no draw is ever meant to be reproducible, by you or anyone else.
When you actually want dice
This tool draws a plain, flat range with every whole number (or, with decimals on, every fine step) equally likely from minimum to maximum. Rolling several dice and adding them is a different shape of randomness entirely, totals cluster around the middle rather than spreading flat, since there are more ways to make a middling total than an extreme one. For that shape, the standard NdS+M dice notation and a running probability chart, the dice roller is this site's dice-shaped version of the same underlying idea.
Choosing a sensible range and count
Set minimum and maximum to the real-world range itself, lottery numbers, a class roster, raffle tickets, rather than a rounded figure; the generator handles any whole-number range up to plus or minus 100,000 either side of zero. How many to draw depends on what is being decided: one settles a coin-flip-style choice, a handful picks winners or a shuffled order, a few hundred is closer to a statistics exercise. Unique should track whether repetition would actually be a problem, a PIN needs it, simulating dice or cards drawn with replacement should leave it off.
Reading the numbers, the chart and the table
"As drawn", ascending and descending only change how the finished list is displayed, never which numbers were drawn or how many times each appeared; sort as drawn first if the order picked actually matters. The stats row shows how many numbers were drawn plus the lowest, highest and mean of that draw, which will not exactly match the range's theoretical midpoint unless the count is large, purely down to ordinary sampling variation. Underneath, "how often each value came up" turns the draw into a bar chart and table, a genuine uniformity check with repeats allowed and a small range relative to the count, since a fair generator spreads counts roughly evenly the more numbers drawn. It is hidden, with a note explaining why, whenever unique draws are on (nothing can repeat by definition) or the range holds far more distinct values than were drawn, since a chart with hundreds of near-empty bars stops being readable long before it stops being accurate.
Questions people ask
Is this random number generator actually unbiased?
Yes. Every number is drawn using the browser's cryptographically secure random number generator, crypto.getRandomValues, combined with a rejection-sampling step that removes the small bias a plain modulo operation would otherwise introduce, so every value in your range has an identical chance.
Why did I get the same number twice?
With "only unique numbers" switched off, every draw is independent of the ones before it, exactly like a lottery machine that puts each ball back before drawing again, so the same value can legitimately come up more than once. Switch unique draws on if repeats would actually be a problem for what you are using the numbers for.
What happens if I ask for more unique numbers than fit in the range?
The count is capped at however many distinct values the range actually contains, and a note says so. A range of 1 to 20 simply cannot produce 30 unique whole numbers, since only 20 exist to draw from.
With decimal places switched on, is every decimal equally likely?
Yes. Decimal places make the range a finer grid of possible values rather than changing how it is drawn from; every one of those finer steps is still selected with the same unbiased method used for whole numbers.
Can I set a seed to reproduce a draw later?
No, deliberately. A seed only makes a sequence reproducible by turning it into a pseudo-random process with a known starting point, which defeats the point of drawing from genuine cryptographic randomness in the first place.
Does changing the sort order change which numbers were drawn?
No. Sorting only changes how the same finished list is displayed, as drawn, ascending or descending. The values, their order of appearance and how many times each one came up are fixed the moment Generate is pressed.
Is this suitable for running a raffle or prize draw?
Yes, provided the range is set to match the actual tickets or entries exactly and unique draws is switched on so nobody can win twice. Publishing the range and count alongside the winning numbers lets anyone confirm the draw matched the real field of entries.
This calculator draws numbers for games, raffles, sampling and general curiosity using your browser's cryptographic random number generator. It has no connection to any specific lottery, contest or platform's own drawing procedure.