Random Number Generator

Picking a winner, sampling rows for a spot check, rolling dice, seeding test data — all the same request: give me numbers in a range, fairly. The generator above does that, with an option for draws without replacement.

How it works

Set min and max — both inclusive, both whole numbers — and how many values you want, from 1 up to 1,000. Then choose between two behaviours:

• With repeats (default) — each value is drawn independently, so duplicates are possible and, in a small range, likely. This is what you want for dice, simulations and anything modelling independent events.
• Unique — values are drawn without replacement, so no number appears twice. The tool builds the full range, shuffles it with a Fisher–Yates shuffle and takes the first n. If you ask for more unique values than the range contains, it tells you how many are actually possible instead of looping forever.

Inputs are validated rather than coerced: a min above the max, a non-integer bound or an out-of-range quantity produces a message. Regenerate draws a fresh set, and Copy all puts the values on the clipboard as a comma-separated list.

The randomness is cryptographic

This matters more than it sounds. The generator uses the Web Crypto API's crypto.getRandomValues(), not Math.random().

Math.random() is a fast pseudo-random generator seeded from an unspecified source. It is fine for animation jitter and shuffling a carousel. It is not fine for anything where someone has an incentive to predict the result, because its internal state can be recovered from a modest number of observed outputs — this has been demonstrated against real browser engines. A prize draw, a token, a raffle, a sampling audit anyone might contest: all of these need a cryptographically secure source, which is what getRandomValues() provides.

The shuffle matters too. Fisher–Yates is the only unbiased way to permute a list in linear time; the popular one-liner array.sort(() => Math.random() - 0.5) produces a measurably non-uniform distribution, because comparison sorts assume a consistent comparator and this one is not.

Everything runs locally. Nothing about your range, quantity or results leaves the browser.

When not to use it

Passwords and keys. A random number is not a password. Use the password generator, which draws from a much larger character space, or the UUID generator for identifiers that need to be unique rather than unpredictable. Never build a secret by concatenating numbers from a range you chose.

Reproducible tests. Cryptographic randomness cannot be seeded, which is the point — and it makes this the wrong tool for test data you need to regenerate identically. Use a seeded PRNG in the test itself, or fix the values as a fixture. A test whose input changes on every run is a test that fails intermittently for reasons nobody can reconstruct. Testing fundamentals covers where determinism belongs and where property-based randomness genuinely helps.

Anything needing an audit trail. The tool keeps no record. For a draw that must be verifiable after the fact, you need a documented procedure and a published seed or commitment, not a browser tab.

Random numbers in security

Predictable randomness is a recurring root cause in security incidents: session identifiers, password-reset tokens, CSRF nonces and initialisation vectors have all been broken by generators that were never meant to resist prediction. The rule is simple and absolute — anything an attacker benefits from guessing comes from a CSPRNG (crypto.getRandomValues() in the browser, SecureRandom in Java, secrets in Python), and everything else can use the fast one. Information security fundamentals covers entropy and where these primitives fit; OWASP Top 10 covers the categories where weak randomness actually shows up.