True Random vs. Pseudo-Random Numbers Explained

Type "random number generator" into a search bar and you will get a tool that produces numbers in well under a second. What almost never gets explained is that there are two fundamentally different ways to build that tool, the true random vs pseudo random divide, and the difference matters far more than it looks. One draws on physical unpredictability from the real world. The other runs a fixed mathematical recipe that only looks unpredictable. Both are useful. Only one of them is safe to build a password generator on top of.

This guide walks through what actually separates true randomness from pseudo-randomness, where each kind comes from, why the distinction becomes a real security question in some situations and a complete non-issue in others, and what statisticians mean when they describe a set of random numbers as having a "uniform distribution."

What makes a number "truly" random

A true random number generator, often abbreviated TRNG, produces numbers by measuring some physical process that nobody can predict or replay, even in principle. The output depends on the messy, chaotic behaviour of the real world rather than on a fixed set of instructions.

People are poor sources of randomness themselves. Ask someone to pick a number between 1 and 10 and 7 is chosen far more often than one time in ten; a machine has no such favourite.

A few real sources of true randomness in everyday use:

• Dice and coin flips. The oldest random number generators humans have ever used. The outcome of a fair die roll or a coin toss depends on tiny variations in force, spin, air resistance and the exact surface it lands on, variations too small and too numerous to predict or control in practice.
• Atmospheric and radio noise. Services like random.org sample static from atmospheric radio noise picked up by ordinary radio receivers. Lightning storms, solar activity and countless other atmospheric events constantly add unpredictable variation to that signal.
• Thermal noise inside electronics. Every electronic circuit generates a small amount of random electrical noise purely from the heat-driven jitter of electrons, known as thermal noise or Johnson-Nyquist noise. Some hardware random number generators, including circuits built into modern CPUs, sample this noise directly as their source of randomness.
• Quantum phenomena. Certain quantum events, such as exactly when a radioactive atom decays or which path a single photon takes through a half-silvered mirror, are understood by physics to be fundamentally unpredictable, not just difficult to predict. A quantum random number generator measures events like these directly, which is about as close to true randomness as anything humans currently know how to build.

The common thread across every one of these sources is that nobody, not even the person running the generator, can work out the next value in advance from the ones that came before it. That property is what makes true randomness the gold standard, and also what makes it comparatively slow and sometimes expensive to produce in bulk: physical measurement takes real time and real hardware, in a way that running a formula does not.

What makes a number "pseudo" random

A pseudo-random number generator, or PRNG, is a deterministic algorithm. Given the same starting input, called a seed, it will produce the exact same sequence of numbers every single time, forever. There is no physical measurement involved at any point; it is pure arithmetic, run over and over, with each step's output feeding into the calculation for the next one.

This is exactly how JavaScript's built-in Math.random() works, and it is the function behind this site's own random number generator. Modern JavaScript engines implement it with a fast, well-studied algorithm, commonly a variant of xorshift, rather than the older linear congruential generators many textbooks use as a teaching example or the once-common Mersenne Twister algorithm still found in many other programming languages and simulation tools. The exact algorithm is not standardised and can differ between browsers and versions, but the underlying idea is the same everywhere: a compact internal state, transformed by a fixed formula, one step per call.

A PRNG's output looks statistically indistinguishable from true randomness across ordinary tests. Run a few million draws through it and check the distribution, the average, the frequency of repeats, and everything looks exactly like what a physical process would produce. That is by design: a good PRNG algorithm is specifically engineered to pass these statistical checks. The catch is entirely about predictability from the inside, not about how the numbers look from the outside. If you know the algorithm and can recover enough of its internal state, in principle you can calculate every number it is about to produce, something that is simply impossible for a true random source built on real-world physical noise.

A brief history of pseudo-random algorithms

Pseudo-randomness is not a recent invention. John von Neumann proposed one of the earliest algorithms in 1946, the middle-square method: square a number, pull the middle digits out of the result to use as the next number, then repeat. It is a beautifully simple idea, and it shows the core weakness of every pseudo-random algorithm that followed: the sequence is entirely determined by the starting number, and a poorly chosen seed can send the method into a short, obviously non-random loop within a handful of steps.

Linear congruential generators (LCGs) became the workhorse for decades, including in many early programming language libraries. An LCG multiplies the current value by a fixed constant, adds another and takes the remainder after dividing by a third. Choose the constants well and it is fast and reasonably well distributed; choose them poorly, as more than one widely used library historically did, and visible patterns appear, particularly in the lower-order bits.

The Mersenne Twister, published in 1997, was a major step forward and remains the default behind Python's built-in random module. Its defining feature is an enormous period, the number of values it can produce before repeating, based on a Mersenne prime with over 19,000 digits, so repetition is never a realistic concern. Its drawbacks are speed and internal state size, which is part of why modern JavaScript engines have largely moved to leaner xorshift-family generators.

None of these algorithms changes the category they sit in. A middle-square generator, an LCG, the Mersenne Twister and a modern xorshift variant are all pseudo-random: fully deterministic, reproducible from a known seed, and never a substitute for a cryptographically secure or physically true random source when predictability would be a real problem.

Why this distinction becomes a real security question

For picking a raffle winner, dealing a hand of cards in a browser game, or drawing a set of sample data to test a spreadsheet formula, the true random vs pseudo random distinction barely matters at all. A pseudo-random generator is faster, needs no special hardware, and is more than good enough.

It matters a great deal the moment randomness is protecting something valuable: a password, an encryption key, a one-time security code, a session token. In those situations, an attacker's entire goal is to predict output that is supposed to be unpredictable. A general-purpose PRNG, including Math.random(), was never built to resist that kind of deliberate attack; it was built to be fast and to look statistically random, not to withstand someone actively trying to reverse-engineer its internal state from observed output. In some JavaScript engines, seeing enough consecutive outputs can in principle let someone reconstruct that state and predict what comes next.

This is exactly why cryptographically secure pseudo-random number generators, or CSPRNGs, exist as their own separate category. A CSPRNG is still, technically, a deterministic algorithm rather than a true random source, but it is specifically designed so that observing its output gives an attacker no practical way to predict future or past values, even with significant computing power. In a browser, that is the Web Crypto API's crypto.getRandomValues(), not Math.random(). The rule of thumb is simple: if predicting the next "random" value would let someone steal money, access, or identity, the tool generating it needs to be a CSPRNG, not a general-purpose PRNG, no matter how random its output looks.

Uniform distribution, explained simply

A random number generator that works correctly should not just be unpredictable, it should also be fair: every possible outcome ought to have an equal chance of showing up. Statisticians call this a uniform distribution.

Uniform is not the only shape. Add two dice and the totals are not uniform: 7 comes up six times as often as 2 or 12, because six of the 36 combinations make a 7 and only one makes a 2. With 3 dice the pile-up around 10 and 11 is stronger still. A gaussian distribution calculator, such as the z-score calculator, handles that bell-curve case.

The clearest everyday example is a fair six-sided die. Roll it, and each of the six faces, one through six, has exactly a one-in-six chance of landing face up. Not five-in-six for the number 4 and one-in-thirty for everything else; each outcome gets an identical slice of the probability. Roll it a few times and you might see some faces more than others purely by chance, the way any small sample can look lopsided, but roll it a few thousand times and the counts settle in close to one-sixth of the total for every face.

The same idea scales up to any range. Ask a well-built random number generator for a whole number between 1 and 100, and every one of those hundred values should have exactly a one-in-a-hundred chance on each draw, with no value quietly favoured over another. Under the hood, a common way to build this is to take a uniformly distributed fraction between 0 and 1 (which is what Math.random() itself returns), multiply it by the width of the target range, and round down to land on one whole number inside it. Because the starting fraction is uniform across its own range, and the transformation spreads that fairness evenly across every whole number in the target range, the final result stays uniform too. This is the exact method behind the range-and-count fields on this site's own random number generator, whether you are generating one number between 1 and 100 or dozens at once.

Uniformity is a separate property from true-versus-pseudo. A generator can be uniformly distributed and still be entirely deterministic and predictable to someone who knows its internal state, which is exactly the situation with Math.random(): statistically fair in its spread of outcomes, while still being pseudo-random rather than physically random underneath.

The gambler's fallacy: why five heads in a row does not make tails "due"

Understanding uniform distribution also means understanding a mistake people make about it constantly: human intuition misreads independent events.

Toss a coin and get heads five times running. What is the probability the next toss is heads? It is not lower than one in two because "tails is due." It is exactly one in two, the same as every toss before it, because each toss is independent: the coin has no memory, and nothing about a physical or algorithmic randomness source changes that. The gambler's fallacy is the belief that a random process should self-correct in the short term, so that a streak of one outcome makes the opposite more likely soon.

The confusion mixes up two questions. Before any tosses, five heads in a row is unlikely: 0.5 multiplied by itself five times is 1 in 32, about 3.1%. That low probability describes the whole five-toss sequence viewed in advance, not the sixth toss viewed afterwards. Once the five heads have happened they are a fact, and the sixth toss starts again from 50/50. Flipping a coin 100 times does not force 50 heads either: the count typically lands within about 5 of 50 and is exactly 50 only about 8% of the time. A rigged coin flip shows itself the same way, as a persistent drift away from an even split over many tosses, never as a single odd result.

The same mistake shows up around this site's own random number generator. Someone who rolls the same number twice on a dice simulator, or watches a raffle draw skip their entry a few times, may feel a change is "due," but a well-built generator with a uniform distribution has no concept of due. The "hot hand" belief, that a streak of good outcomes predicts more of them, makes the identical mistake in the opposite direction. None of this changes with more decimal precision or a fancier algorithm: a flawless, independent generator still produces the occasional long streak, because long streaks are a normal feature of enough independent trials.

Precision is not the same thing as randomness

It is worth separating two ideas that sound related but are not. A random number generator's Comprehensive Version, the kind that can produce a decimal result with dozens or hundreds of digits after the point, is not "more random" than a simple version that only produces whole numbers. Precision describes how many digits you see. Randomness describes how unpredictable and how uniformly distributed those digits are. A tool built to generate long decimal results honestly, digit by digit, with each digit drawn independently, is just as reliant on the same underlying pseudo-random source as any other mode; it has simply been engineered so that asking for more digits does not introduce rounding artefacts or run into the limits of ordinary floating-point numbers.

When true randomness is worth the extra effort

For all the ways pseudo-random numbers are good enough, some situations genuinely call for the real thing. National lotteries typically use certified hardware random number generators, sometimes alongside mechanical ball-draw machines, specifically because the payout is large enough that predictability would be a serious problem. Cryptographic key generation, the kind that protects encrypted messages and secure website connections, draws on operating-system-level entropy sources that blend hardware noise with other unpredictable system events. Some scientific simulations and statistical sampling work, particularly in fields like cryptographic research itself, specifically call for a certified true or cryptographically secure source rather than a general-purpose PRNG, precisely because the whole point of the exercise is testing or relying on unpredictability itself.

For everyday choices, software is plenty. A true RNG adds nothing to a raffle, and a yes no coin flipper settles a lunch order as fairly as a physical coin. A DnD dice roller or d20 dice roller, like the site's dice roller, only needs results that look fair, such as a number randomly drawn from a range.

For nearly everything else, from rolling virtual dice to picking a random sample of survey respondents to simply settling an argument about who does the dishes, a well-built pseudo-random generator with a genuinely uniform distribution is exactly the right tool, and reaching for anything more elaborate would be solving a problem that was never actually there.

True random vs pseudo random: the questions people search

Answering the true random vs pseudo random question for a random number generator built on Math.random(), including the one on this site, is straightforward: it sits firmly in the pseudo-random category. That is not a limitation to apologise for; it is the correct, standard choice for a tool built for games, sampling, classroom demonstrations and everyday decision-making, the same way a kitchen scale is the right tool for baking even though a laboratory balance is more precise. Reaching for a hardware or cryptographically secure random number generator only makes sense once the numbers being produced are protecting something an attacker would want to predict.

A request like "Siri, flip a coin" is answered by software, which means a pseudo-random generator. The same ideas cover a lottery quick pick, a non repeating random number list and any task to randomize list order: each draws from a pseudo-random source and only needs it to look fair.