You are drawing five giveaway winners from 1 to 100. You hit generate and get 7, 41, 88, 41, 12.
Forty-one, twice. So you draw again, quietly assuming the tool glitched.
It did not. That result is supposed to happen roughly one time in ten — and if you have run a few giveaways this way, the odds are good that one of them was decided by a draw you should have thrown out.
The repeat is not a bug in the generator. It is a mismatch between what you asked for and what you meant. This guide covers the actual numbers, why they are so much higher than people expect, and how to generate unique random numbers instead.
A Repeat Means It Is Working
A random number generator in its default mode does exactly one thing per number: it picks a value from your range, uniformly, and then forgets it ever happened.
Math.floor(Math.random() * (max - min + 1)) + minAsk for five numbers and it runs that five separate times. There is no shared memory between the calls, which means a number that came up on draw two is exactly as likely on draw three as any other. Statisticians call this sampling with replacement — as though you drew a ticket from a hat, wrote it down, and dropped it back in.
A generator that silently refused to repeat would actually be the broken one. The moment it starts avoiding used values, each draw stops being uniform over your full range — the numbers already taken drop to zero probability, which is exactly what the default mode promises not to do. Avoiding repeats is a perfectly good thing to want. It is just a different draw, not a fixed version of the same one.
So both behaviours are correct. They just answer different questions:
- Allow repeats — "give me five independent numbers", like rolling one die five times.
- Unique only — "give me five different numbers", like dealing five cards off one deck.
For a giveaway you almost always mean the second one. The default is the first.
How Often a Duplicate Actually Happens
Here is where intuition fails badly. With 100 possible numbers and only 5 picks, a collision feels remote — you are using 5% of the range.
But you are not comparing each number against the range. You are comparing every number against every other number, and the number of those pairs grows far faster than the count does. Five picks make ten pairs; ten picks make forty-five.
These are exact probabilities of getting at least one duplicate, with repeats allowed:
| Range | 3 picks | 5 picks | 10 picks | 20 picks |
|---|---|---|---|---|
| 1 – 10 | 28.00% | 69.76% | 99.96% | 100% |
| 1 – 20 | 14.50% | 41.86% | 93.45% | 99.99% |
| 1 – 50 | 5.92% | 18.64% | 61.83% | 98.80% |
| 1 – 100 | 2.98% | 9.65% | 37.18% | 86.96% |
| 1 – 500 | 0.60% | 1.99% | 8.66% | 31.96% |
| 1 – 1000 | 0.30% | 1.00% | 4.41% | 17.41% |
Read the 1–100 row. Five winners carries a 9.65% chance of a repeat — that is the one-in-ten from the opening. Ten winners from the same range is 37.18%, better than one in three. And picking 5 from 1–50, which is what a small giveaway looks like, fails 18.64% of the time.
Even a range of 1–1000 does not make the problem disappear. Twenty picks from a thousand still repeats 17.41% of the time, which is roughly one giveaway in six.
The Point Where a Repeat Becomes Likely
Another way to frame the same thing: how many numbers can you draw before a duplicate becomes more likely than not?
| Range | Draws until a repeat is over 50% likely |
|---|---|
| 1 – 10 | 5 draws |
| 1 – 50 | 9 draws |
| 1 – 100 | 13 draws |
| 1 – 500 | 27 draws |
| 1 – 1000 | 38 draws |
| 1 – 10000 | 119 draws |
Thirteen draws out of a hundred numbers, and a repeat is the favourite. Multiply the range by a hundred, from 100 to 10,000, and the safe number of draws only grows from 13 to 119 — roughly nine times, not a hundred. That square-root relationship is why widening the range is such a weak defence.
Which leaves one honest conclusion: if you need distinct values, do not try to buy safety with a bigger range. Ask for distinct values.
What "Unique Only" Actually Changes
Switching the toggle from Allow Repeats to Unique Only does not add a retry loop that discards duplicates. It changes the method entirely.
For an ordinary range the tool builds the full list of candidate values, shuffles it with a Fisher-Yates shuffle, and takes however many you asked for off the top. Every value in the range appears exactly once in that list, so the result cannot contain a duplicate — not because duplicates were filtered out, but because there was never a second copy to draw.
Fisher-Yates matters here. Implemented correctly, and given an ideal source of randomness, it makes every possible ordering equally likely — so slicing the first five entries off the top is a genuinely fair sample of five distinct values. The tempting alternatives are not equivalent: sorting by a random comparator, or swapping each item with any position in the whole list rather than only the unshuffled part, both skew the results toward certain orderings. (The "ideal source" caveat is doing real work in that sentence, and the next section is about exactly what it hides.)
For very wide ranges, building the whole list would be wasteful, so the tool switches to drawing values and skipping any it has already seen. Same guarantee, different route: with a huge range and at most 20 picks, collisions are rare enough that this stays fast.
The Shuffle Limit Nobody Mentions
There is a real limitation in unique mode, and it is not the one people worry about. It is worth stating plainly, because most pages on this topic skip it.
A shuffle is driven by Math.random(), which in Chrome and Edge is an algorithm called xorshift128+ carrying 128 bits of internal state. That gives about 3.4 × 1038 distinct states the generator can ever be in.
Now count the orderings of a list. A range of 34 values has 34! ≈ 2.95 × 1038 possible orderings, which still fits. A range of 35 has 35! ≈ 1.03 × 1040 — already thirty times more orderings than the generator has states.
So from 35 values upward, a shuffle cannot produce every possible ordering. Shuffle a range of 100 and the reachable orderings are a vanishing fraction of the 9.3 × 10157 that exist.
For a giveaway, a classroom activity, or picking a test fixture, this is trivia. It is included because a page telling you a tool is flawless is not telling you the whole story — and the same caveat applies to the underlying 50/50 question, which the guide on whether a virtual coin flip is fair works through in detail.
Which Mode for Which Job
The rule is short: ask whether drawing the same value twice would be a valid outcome in real life.
| What you are doing | Mode | Why |
|---|---|---|
| Picking giveaway or raffle winners | Unique only | One person cannot win two prizes in a single draw |
| Lottery-style number picks | Unique only | Real draws remove each ball from the machine |
| Assigning numbers to a group | Unique only | Two people sharing a number defeats the purpose |
| Simulating dice or repeated trials | Allow repeats | Rolling the same face twice is a real outcome |
| Generating test or sample data | Allow repeats | Real data contains duplicates; removing them makes it unrealistic |
| Picking one number, once | Either | With a single pick there is nothing to collide with |
If the answer is "that would be a valid outcome", leave repeats on. If the answer is "that would be a mistake I would have to undo", switch to unique.
Generating Numbers Without Repeats
- Open the Random Number Generator.
- Set your min and max. For a giveaway these are the first and last entry numbers — if you have 250 entries, that is 1 to 250, not 1 to 100.
- Enter how many numbers you need, up to 20 in one draw.
- Click the toggle so it reads "Unique Only". This is the step that matters, and it is the one that gets skipped — the button starts on Allow Repeats.
- Generate, then check the recent-draws list underneath. It keeps your last ten draws, which is what you want if someone later asks how the winners were picked.
Everything runs in your browser. No draw is sent to a server, which also means nobody — including this site — can see or alter a result before you do.