Random Number Generator

This random number generator (also called an RNG, random number picker, or random integer generator) returns one or more numbers drawn uniformly from any range you set. Use it to pick a random number between 1 and 100, roll a d20, draw raffle winners, or generate a list of sample IDs. Every click runs a fresh draw, so you can regenerate as many times as you need.

1. Set the minimum number. This is the smallest value that can appear in the result. The range is inclusive, so entering 1 means 1 is a possible outcome.
2. Set the maximum number. This is the largest value the generator can return, also inclusive. For a classic random number between 1 and 100, leave the default 1 to 100.
3. Choose how many numbers to generate. Enter 1 for a single pick or up to 1,000 for a batch. Use larger batches for sampling, quiz questions, or seeding a spreadsheet.
4. Toggle no duplicates. Leave this on when you need unique numbers (lottery picks, raffle winners, a random order without repeats). Turn it off for independent rolls like dice or coin flips where repeats are allowed.
5. Toggle sort order. Ascending sort is useful for lottery tickets and audit samples. Leave it off to preserve the order the numbers were drawn in.
6. Click Generate. Click again for a new random set. Use the quick presets for common use cases such as 1 to 6 dice, a coin flip, a 1 to 49 lottery, or a full 1 to 1000 range.

The sum and average shown under batch results are handy for quick sanity checks: over a large draw, the average should sit near the midpoint of your range. If it does not, you either asked for a very small sample or you are looking at normal short-window variance from a random draw.

Picking a random integer sounds simple, but under the hood a random number generator has to decide two things: where the randomness comes from, and how to turn that raw randomness into a number inside your chosen range. This section walks through both, with the actual math.

Pseudo-Random (PRNG) vs True Random (TRNG)

A pseudo-random number generator (PRNG) uses a deterministic algorithm seeded from something time-like (the current millisecond, a counter, a process ID). Examples include JavaScript's Math.random, the Mersenne Twister used by Python and many game engines, and xorshift variants used in high-speed simulations. Given the same seed, a PRNG always produces the same sequence. It is fast, reproducible, and statistically uniform over long runs, but it is not secret.

A true random number generator (TRNG) pulls entropy from a physical process: atmospheric radio noise (random.org), thermal noise in a resistor, radioactive decay, or the timing jitter of keyboard presses and disk I/O that feeds /dev/random on Linux. TRNGs are slower and harder to reproduce, but their output cannot be predicted even if you know everything about the hardware.

Linear Congruential Generator (LCG) Formula

The oldest and simplest PRNG is the linear congruential generator. It advances one number at a time using:

Xn+1 = (a × Xn + c) mod m

a = multiplier, c = increment, m = modulus, X0 = seed

Pick good constants and you get a long, well-distributed cycle. Pick bad constants and the output repeats quickly or clumps in predictable patterns. Modern languages have mostly moved on to Mersenne Twister, PCG, or xoshiro families, but LCGs still show up inside embedded systems and older library code.

Uniform Integer Draw From [min, max]

Once the underlying PRNG produces a floating-point value rand() in [0, 1), turning it into a uniform integer in the inclusive range [min, max] uses one line of math. This is the exact formula the widget above runs:

r = min + ⌊rand() × (max − min + 1)⌋

Example: min = 1, max = 100, rand() = 0.7324
r = 1 + ⌊0.7324 × 100⌋
r = 1 + 73
r = 74

The floor (⌊ ⌋) and the + 1 inside the multiplier are what make both endpoints reachable. Without the + 1, the maximum would never come up. Without the floor, you would get a decimal instead of an integer.

Drawing Without Replacement (Fisher-Yates Concept)

When the "no duplicates" box is checked, the draws are no longer independent. Each number that is picked has to be removed from the pool so it cannot come up again. The clean way to do this is a Fisher-Yates shuffle: fill an array with every number from min to max, then swap random pairs until the array is shuffled, then read off the first N values. The widget above uses an equivalent pool-and-splice variant.

Step 1: pool = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
Step 2: pick index 3 → draw 4, pool = [1, 2, 3, 5, 6, 7, 8, 9, 10]
Step 3: pick index 7 → draw 9, pool = [1, 2, 3, 5, 6, 7, 8, 10]
Step 4: pick index 0 → draw 1, pool = [2, 3, 5, 6, 7, 8, 10]
... repeat until you have the count you asked for

Because each draw changes the pool, the probability of the remaining numbers shifts every step. On a lottery-style 6-of-49 draw, the first number has a 1 in 49 chance, the second has a 1 in 48, and so on.

Probability of Each Number in a Uniform Draw

In a single uniform draw from [min, max], every integer has the same probability:

p = 1 / (max − min + 1)

Range 1 to 100:   p = 1 / 100   = 1.00%
Range 1 to 6:     p = 1 / 6     ≈ 16.67%
Range 0 to 1:     p = 1 / 2     = 50.00%
Range 1 to 1000:  p = 1 / 1000  = 0.10%

That 1 in 100 figure is why "pick a random number between 1 and 100" is such a common fairness test: it is easy to see by eye if a supposedly random sequence is overweighted toward certain endpoints or digits.

Quick Reference: Common RNG Types Compared

The widget on this page uses Math.random, which is excellent for the use cases it targets (games, draws, sampling, teaching) and should not be used for anything where an attacker guessing the next number would cause harm.

A random number generator looks trivial from the outside: click a button, get a number. The interesting questions are about how people use the output. Is a 5-in-a-row result actually fair? When does a regular RNG stop being safe? Where do real-world systems get the randomness part wrong? This section answers each of those.

Common Uses for a Random Number Generator

If your use case is on that list, the widget above is a fit. If your use case is on the security list in the next section, it is not.

Is It Truly Fair? PRNG Bias and the Gambler's Fallacy

A quality PRNG is statistically fair: over thousands of draws, every number in the range appears with the same frequency. Short windows look very different. In 20 rolls of a six-sided die, a perfectly fair generator will usually produce at least one number that appears three or more times and at least one that never appears at all. That is not a bug. It is the actual expected behavior of random draws.

Getting five 7s in a row from a range of 1 to 100 has a probability of about 1 in 10 billion. It is extraordinarily unlikely in any single batch, but across millions of page loads it will happen to somebody. If you regenerate, the next number still has a flat 1 in 100 chance of being 7. This is the gambler's fallacy: the belief that a number is "due" after a streak, or that a recent winner "cannot come up again." Each draw is independent. The generator has no memory of the previous one.

Short-run clumping is where people lose faith in RNGs and incorrectly call them rigged. The right way to test a generator is a chi-squared test on at least 1,000 draws, not eyeballing ten.

When to Use a Cryptographic RNG Instead

A normal RNG like Math.random is designed to be fast and statistically uniform. It is not designed to be unpredictable to an attacker who has seen some of its output. A cryptographic RNG is. Use one whenever the number must not be guessable by someone watching your traffic, your logs, or your app.

The short rule: if the attacker seeing old output would help them guess future output, you need a cryptographic RNG. In a browser use crypto.getRandomValues(). On a server use your language's crypto module (Python's secrets, Node's crypto.randomBytes, Go's crypto/rand). Never use Math.random for anything security-related.

Real-World PRNG Exploits

The "just use a PRNG" mistake has broken production systems repeatedly. A few well-documented cases:

• Sony PlayStation 3 ECDSA signing key (2010). Sony used the same secret random number to sign every firmware update instead of a fresh draw each time. Two signatures with the same nonce leaked the private signing key through basic algebra, giving hackers the ability to sign any code as Sony. A proper random draw each time would have prevented it.
• Online poker seeding (2001, Reliable Software Technologies). A commercial online poker site seeded its shuffle with a 32-bit PRNG tied to the server clock. Researchers recovered the full deck in real time by observing the first five cards and brute-forcing the seed, then predicting the rest of the deck before the hand finished.
• Debian OpenSSL weak-key bug (2008). A two-line change to Debian's OpenSSL reduced the entropy pool to 15 bits of randomness. Every SSH and SSL key generated on affected systems for nearly two years was one of roughly 32,000 possible keys, all of which an attacker could precompute. Hundreds of thousands of keys had to be revoked.
• Cryptocurrency wallet brain-wallets and weak seeds. Wallets that generated keys from a low-entropy PRNG or user password have been drained within seconds of being funded because attackers sweep the known weak-key space continuously.

Each of these failed the same way: someone assumed a generator that looked random was random enough for security. The lesson is not that randomness is hard in general. Picking a dice roll is easy. The lesson is that cryptographic randomness is a different product with different requirements, and the two look identical until someone tries to break them.

Where This Generator Fits

The RNG on this page is a fast, uniform PRNG suitable for games, draws, sampling, homework, brainstorming, and teaching probability. It is not a cryptographic RNG and should not be used to generate passwords, tokens, encryption keys, or any number that an attacker must not be able to predict. For those cases, use a language-provided crypto RNG or a certified hardware random source.