Random Number Generator Calculator

Understanding the Random Number Generator Calculator

A random number generator returns values in a range using the browser's built-in function. It is suitable for games, sampling, and picking a winner, and it is explicitly not suitable for anything security-related, because the underlying generator is predictable by design.

How it actually works

Enter minimum, maximum, and how many numbers to produce, up to 100. The calculator generates each value by scaling the browser's random function across the inclusive range and flooring the result.

The deeper context most people miss

The browser's Math.random is a pseudorandom generator, meaning it produces a deterministic sequence from an internal state. Given enough output, that state can be reconstructed and future values predicted, which has been demonstrated against common implementations, so anything where predictability matters needs a different source.

Why pseudorandom and cryptographic generators differ

A pseudorandom number generator starts from a seed and applies a deterministic function repeatedly, producing a sequence that passes statistical tests for randomness while being entirely reproducible from the seed. That reproducibility is a feature for simulation and testing, where being able to rerun an experiment with identical random values matters, and it is a fatal flaw where an adversary must not be able to predict future values. Common implementations including the xorshift family used in several JavaScript engines have relatively small state, and researchers have demonstrated recovering that state from a modest number of observed outputs and then predicting the remaining sequence. Cryptographically secure generators are built differently: they draw entropy from unpredictable physical sources including hardware noise, timing jitter, and interrupt patterns, maintain a much larger internal state, and are designed so that observing outputs does not reveal the state. In browsers this is exposed as crypto.getRandomValues, in Node as the crypto module, and in most languages as a dedicated secure random class distinct from the general-purpose one. The distinction matters practically because using the general-purpose generator for tokens, session identifiers, password reset links, or shuffle in gambling contexts is a recognised vulnerability class, and it has caused real breaches. The rule is simple: if predicting the value would benefit someone, use the cryptographic source.

A worked example: where naive generation goes wrong

Generating an integer by scaling a fractional random value and flooring it is correct when done as this calculator does, taking the floor of random times the range size plus one, then adding the minimum. A common error is using modulo on a random integer, which introduces bias when the range does not divide evenly into the generator's output space, so some values appear slightly more often than others. The bias is small for small ranges and large generators, and it is real and has mattered in cryptographic contexts, which is why secure implementations use rejection sampling, discarding values in the biased tail and drawing again. A related error appears in shuffling: the naive approach of sorting with a random comparator produces a distribution that is not uniform and is measurably biased, and the correct method is the Fisher-Yates shuffle, which walks the array swapping each element with a randomly chosen one from the remaining unshuffled portion, producing every permutation with equal probability. This matters for anything where fairness is claimed. Another frequent issue is generating numbers in a loop and assuming independence when the generator has been reseeded from a low-entropy source such as the current time in seconds, which can produce identical sequences across processes started in the same second, a documented cause of duplicate identifiers.

Deciding what source to use for what

For games and simulations, the built-in generator is appropriate and fast. For anything statistical where reproducibility matters, a seeded generator with an explicitly recorded seed is better than the built-in one, since it allows rerunning an analysis identically, and several libraries provide this. For scientific work with strict requirements, generators with long proven periods including Mersenne Twister and the PCG family are standard, and Mersenne Twister despite its ubiquity is not cryptographically secure and should not be used where prediction matters. For security, use the platform's cryptographic source: crypto.getRandomValues in browsers, the crypto module in Node, SecureRandom or equivalent in other languages, and dedicated key generation functions rather than assembling keys from general random output. For competitions, prize draws, and anything where a participant might dispute the outcome, the technical quality of the generator is only part of the requirement, since the process must also be demonstrable: publishing a commitment to a method beforehand, using a verifiable public source of randomness such as a lottery draw or a published beacon, or having the draw witnessed all serve that, and several jurisdictions regulate prize draws with specific requirements. For gambling, regulated operators are required to use certified generators subject to independent testing.

Where true randomness comes from

Hardware random number generators derive values from physical processes believed to be genuinely unpredictable rather than merely complex. Thermal noise in resistors, avalanche noise in semiconductor junctions, and jitter in free-running oscillators are common sources, and modern processors from several manufacturers include on-die generators exposed through dedicated instructions. Quantum sources, typically based on photon behaviour at a beam splitter or on radioactive decay timing, are used where the strongest theoretical guarantees are wanted, and several services publish quantum-derived random data. Operating systems maintain entropy pools that collect unpredictability from hardware sources, interrupt timing, and user input, and expose it through interfaces that mix and stretch it cryptographically, which is what platform secure random functions ultimately draw on. A historical concern was entropy starvation on headless servers and embedded devices lacking user input, which produced real vulnerabilities where keys were generated at first boot with insufficient entropy, and a widely cited study found substantial numbers of internet-facing devices sharing keys for exactly this reason. Modern kernels and hardware generators have largely addressed it. Public randomness beacons publish timestamped random values with cryptographic proofs, allowing anyone to verify that a value existed at a stated time without being chosen afterwards, which suits lotteries and audit applications where the concern is manipulation rather than prediction.

Variations: distributions, sampling, and seeded reproducibility

Uniform distribution is what this generator produces, with every value in the range equally likely. Other distributions are derived from uniform values through transformation: the Box-Muller transform produces normally distributed values, inverse transform sampling handles distributions with an invertible cumulative function, and rejection sampling handles awkward ones. Weighted selection, where outcomes have different probabilities, is handled by cumulative ranges. Sampling without replacement requires tracking used values or shuffling and taking a prefix, and the naive approach of generating and discarding duplicates degrades badly when the sample approaches the population size. For random sampling in statistics, the sampling frame and method matter far more than the generator, since a perfect generator applied to a biased frame produces a biased sample. Seeded generation with a recorded seed enables reproducible analysis and is standard practice in scientific computing, where publishing a seed alongside results allows verification. For testing, property-based testing frameworks generate random inputs and report the seed on failure so the failing case can be reproduced, which is a genuinely useful application of controlled pseudorandomness.

Using random numbers appropriately

Use this generator for games, shuffling, informal draws, and simulations, where the built-in pseudorandom source is entirely adequate. Use the platform's cryptographic source instead for passwords, tokens, session identifiers, keys, and anything where predicting the value would benefit someone, since pseudorandom state can be reconstructed from observed output. Avoid modulo for range reduction in security contexts, since it biases the distribution when the range does not divide evenly, and use rejection sampling instead. Use Fisher-Yates for shuffling rather than sorting with a random comparator, which produces a measurably non-uniform distribution. Record and publish a seed where reproducibility matters, which is standard practice in scientific computing and enables verification. Use a demonstrable process rather than a private script for prize draws, whether a public beacon, a witnessed draw, or a published commitment, since fairness must be shown as well as achieved. And check regulatory requirements for gambling and prize promotions, which specify certified generators and defined procedures in many jurisdictions.

What people get wrong

• Using a general-purpose random function for tokens, keys, or session identifiers, when its internal state can be reconstructed from observed output and future values predicted.
• Reducing a random value into a range with modulo, which produces a slightly non-uniform distribution when the range does not divide evenly into the generator's output space.
• Shuffling by sorting with a random comparator, which is measurably biased, rather than using Fisher-Yates which produces every permutation with equal probability.
• Running a prize draw with a private script, when fairness needs to be demonstrable through a witnessed process, a published commitment, or a verifiable public randomness source.

Where the math comes from

Each value is generated as floor(random × (Maximum - Minimum + 1)) + Minimum, where random returns a fractional value in [0, 1). This yields a uniform distribution across the inclusive range without the modulo bias that arises when a range does not divide evenly into the generator's output space. The underlying source is pseudorandom and deterministic given its internal state, so it is unsuitable for security purposes.

Questions and answers

Related calculators

Audio Bitrate · Gravel · Meeting Cost · Typing Speed · Electric Vehicle Range