Random Number Generator

1. True randomness vs pseudo-randomness

A computer is deterministic by design — the same input, same program, same state produces the same output. “Random” numbers from a computer are therefore not truly random; they are pseudo-random, the output of a deterministic algorithm seeded by some external value. JavaScript’s Math.random() is the classic example: it produces a stream of numbers that pass standard statistical tests for uniformity but is fully predictable if you know the internal state. This tool draws from the browser’s cryptographic source instead, crypto.getRandomValues(), and layers rejection sampling on top to remove the modulo bias a naive range mapping introduces. For every non-security use that is exactly right: statistically uniform, fast, and free of any server round trip.

2. Why pseudo-random is plenty for most uses

Pick a winner from a raffle, roll a virtual die, shuffle a playlist, sample a row from a spreadsheet, drop a piece on a game board — in each of these the requirement is statistical uniformity over many runs, not unpredictability against an attacker. A generator like the one behind this tool delivers that with a single call. The values returned are uniformly distributed across your specified range, and generating one hundred of them in a single click produces a sequence with no obvious bias when inspected visually or histogrammed. For classroom demonstrations, casual games, surveys, and statistical sampling, this is the right kind of random.

3. Why pseudo-random is not enough for security

The moment you need unpredictability against an adversary, a plain pseudo-random generator becomes the wrong tool. Security contexts — generating a password reset token, picking a session identifier, creating a one-time pad, deriving an encryption nonce — require that an attacker who has watched previous outputs cannot predict the next one. Weak generators fail that test catastrophically: their state space is bounded, and once an attacker observes enough output, they can reconstruct the internal state and predict every future value. Several high-profile breaches — including the Debian SSH key vulnerability of 2008 — traced back to flawed randomness of exactly this kind. This tool already draws from the Web Crypto API with bias removal, so its output is uniform and unpredictable at 32 bits of entropy per call; what it does not do is give a secret the length, alphabet, and entropy accounting that a credential needs. For that, use a generator built and documented for it — the Random String Generator tool on this site is the right choice for passwords, tokens, and salt values.

4. Range, count, and the “swap” behaviour

The interface accepts a minimum, a maximum, and a count between 1 and 100. If you set min greater than max, the tool silently swaps them — generating the range the way you almost certainly meant, rather than erroring out. The count cap of 100 is a deliberate guard against a runaway call: requesting more than 100 values in one click would be either a typo or a misuse, both of which the limit catches. The history panel retains the last ten results so you can refer back without re-generating.

5. The quick presets — common probability distributions

The five preset buttons situate the generator in the most common sampling cases: d6 (1–6) and d20 (1–20) model the standard tabletop dice; the coin (0–1) preset models a binary “success/failure” outcome — a Bernoulli trial — useful for monte-carlo simulations of “did this happen or not?”; the 1–100 preset is the standard “percentage roll” used in countless games and surveys; and the lottery (5 of 1–50) preset switches to unique, sorted picks, the shape almost every draw-a-winner problem takes. Switching between them is one click; the values returned are uniform across the stated range.

6. Reproducibility — a feature you do not have here

Some workflows want reproducible randomness — the same seed produces the same sequence — for testing, simulation playback, or debugging. This tool does not expose a seed: its numbers come from the browser’s cryptographic source, which has none to set. If reproducibility is what you need, the canonical approach is a seeded pseudo-random generator such as mulberry32or the Mersenne Twister; both are small enough to inline in any project. This tool is for ad-hoc, “give me a random draw right now” cases where reproducibility is the opposite of what you want.

7. Privacy and the browser-side model

A random draw is sometimes sensitive — survey sampling, audit selection, sweepstakes results. Uploading the parameters to a remote service to get the number means the service knows what you drew, when, and possibly why. This tool runs entirely in your browser: every number is computed locally, stored only in the on-page history, and never transmitted. There is no log on any server of what you generated or when. Confidentiality is structural, not promised.

Right Randomness for the Right Job

Random number generation is a more nuanced problem than it looks, but the operating rule is simple: for statistical and casual use — dice, picks, sampling, games — a bias-free random source is the right choice, and this tool uses one, uniform across any range and up to a hundred values at a time with no upload. For security use — tokens, keys, nonces — reach for a generator designed for secrets instead, such as the Random String Generator. Mixing the two up is the single most expensive mistake you can make in this domain; keeping them straight is the only thing that really matters here.