The Complete Guide to Random Number Generation
A random number generator seems like the simplest of tools: you press a button, you get a number. Behind that one click sits a surprisingly deep question — random by what measure, and for what purpose? A number picked for a classroom game and a number picked for a one-time pad encryption key live at opposite ends of a quality spectrum, and conflating the two has produced some of the most expensive security failures in computing history. This page explains what “random” actually means in a browser, how this generator behaves, and which problems it should and absolutely should not be used for.
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(), which this tool uses, is the canonical pseudo-random generator: it produces a stream of numbers that pass standard statistical tests for uniformity but is fully predictable if you know the internal state. For almost every non-security use, that is exactly right — fast, statistically uniform, and free of the overhead that true randomness requires.
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. Math.random delivers that with one or two instructions per call. The values returned by this tool 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, Math.random 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. Pseudo-random 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. For security, use the Web Crypto API (crypto.getRandomValues()) instead — the Random String Generatortool on this site uses that API directly and is the right choice for security tokens, salt values, and any context where “the attacker can’t guess this” is the requirement.
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 four 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?”; and the 1–100preset is the standard “percentage roll” used in countless games and surveys. 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 because Math.random does not accept one in the standard. 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.
Conclusion
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 — Math.random-based pseudo-randomness is the right choice and this tool uses it correctly, uniformly across any range, up to a hundred values at a time, with no upload. For security use — tokens, keys, nonces — reach for the Web Crypto API and the Random String Generator tool instead. 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.