The Science of Leaving It to Chance
Explore the surprising research behind random decision-making. Learn why mathematicians, psychologists, and economists agree that sometimes chance is the optimal choice.
Every time you click a "randomize" button, flip a coin tool, or roll a virtual die, your computer is doing something philosophically strange: it's producing a number that looks random but actually isn't. Not in the purest sense. Computers are deterministic machines — given the same input, they'll always produce the same output. So when your browser generates a "random" number between 1 and 100, something more interesting is happening under the hood than you might expect.
Why Computers Can't Be Truly Random (By Themselves)
True randomness, at a physical level, comes from unpredictable natural phenomena — the exact moment a radioactive atom decays, the quantum fluctuations of electrons, or the chaotic turbulence of atmospheric pressure. These events genuinely have no predetermined outcome. A computer running a program, however, just executes instructions. Step A produces step B, which produces step C. There's no room for genuine unpredictability in that chain.
This is why the field distinguishes between true random number generators (TRNGs) and pseudorandom number generators (PRNGs). A PRNG starts with a "seed" value and then applies a mathematical formula repeatedly to generate a long sequence of numbers that looks statistically random. If you know the seed, you can reproduce the entire sequence from scratch. That's the catch — it's deterministic at its core.
A TRNG, on the other hand, measures something genuinely unpredictable in the physical world and converts it to a number. The website random.org has been doing this since 1998, using atmospheric noise captured by radio receivers. It's a bit like asking the weather to decide your lottery numbers — except the weather is actually unpredictable at the required scale.
The Mersenne Twister: The PRNG That Runs Most of the World
The most widely deployed PRNG in the world is the Mersenne Twister (MT19937), developed by Makoto Matsumoto and Takuji Nishimura in 1997. It has a period of 219937−1, which means it generates about 4.3 × 106001 numbers before repeating. For practical purposes, you will never see it cycle. The numbers it produces pass essentially all standard statistical tests for randomness.
Python's random module uses the Mersenne Twister. So does PHP, Ruby, and many other languages. It's genuinely excellent at producing numbers that feel random — in the sense that they're uniformly distributed and don't show obvious patterns.
But the Mersenne Twister has one serious weakness: it's not cryptographically secure. If an attacker observes 624 consecutive outputs from the generator, they can fully reconstruct its internal state and predict every future number. This matters a lot if you're generating session tokens, passwords, or encryption keys. For a game of virtual dice, though? The Mersenne Twister is completely fine.
JavaScript's Math.random() vs. crypto.getRandomValues()
When you call Math.random() in JavaScript, you get a PRNG. The spec doesn't even mandate which algorithm to use — V8 (Chrome's engine) uses xorshift128+, which is fast and statistically fine, but again, not cryptographically secure. The seed is typically set from the system clock or some OS-level entropy at startup.
For anything security-sensitive, the Web Cryptography API provides crypto.getRandomValues(), which pulls entropy from the operating system's entropy pool. On Linux, that pool is seeded from hardware events — keyboard timings, disk interrupts, network packet arrival times, and yes, thermal noise from hardware sensors. On modern systems with Intel's RDRAND instruction, there's dedicated hardware that samples on-chip thermal noise to generate random bits directly. This is about as close to a true hardware RNG as you get in a consumer device.
For the random number generator and coin flip tool on this site, Math.random() is perfectly appropriate — nobody's life depends on whether heads or tails comes up. But it's worth knowing that there's a spectrum from "fast and good enough" to "cryptographically unbreakable."
Where True Randomness Actually Matters
The distinction between PRNGs and TRNGs stops being theoretical the moment real stakes appear. Here are three domains where the difference is genuinely consequential:
Cryptography. Encryption keys, session tokens, and one-time passwords must be generated with cryptographically secure randomness. If an attacker can predict your session token, they can impersonate you. The PlayStation 3's ECDSA signing famously reused the same "random" nonce due to a poor RNG implementation — this allowed hackers to extract the private key and break the entire console's security.
Monte Carlo simulations. Scientists and financial analysts use random sampling to model complex systems — everything from particle physics to portfolio risk. These simulations require very long sequences with no detectable statistical bias. The Mersenne Twister was specifically designed for this use case and handles it well, though newer alternatives like PCG (Permuted Congruential Generator) are gaining ground for better performance characteristics.
Fair lotteries and elections. When random selection determines who wins money or public office, the process needs to be not just random but auditable. Some jurisdictions publish the seed used in digital lottery draws so anyone can verify the outcome was pre-committed before the draw. Others use physical ping-pong balls precisely because "algorithmic skepticism" from the public is a real concern, even when the algorithm is demonstrably sound.
Seeding: The Critical but Often Overlooked Variable
A PRNG is only as unpredictable as its seed. In the early days of computing, some programs seeded their generators with a fixed value — meaning every run produced the exact same "random" sequence. This was a bug, but a surprisingly common one. Even seeding with the system clock can be weak if the attacker knows approximately when the process started.
Modern operating systems solve this by maintaining a continuously updating entropy pool that mixes together dozens of unpredictable hardware events. When a program asks for entropy, it draws from this pool. The pool never runs dry because events keep happening — you're always moving your mouse, your disk is always doing I/O, packets are always arriving on the network. This is why security professionals are careful about generating cryptographic keys on freshly booted virtual machines that haven't yet accumulated much entropy: the pool might be thin.
The NIST SP 800-90A standard specifies exactly how deterministic random bit generators should be constructed for security-sensitive applications, including how to seed them properly from entropy sources. It's dense reading, but it gives you a sense of how seriously cryptographers take the question of "where does the randomness actually come from?"
What This Means for Everyday Random Tools
Most of the time, none of this matters for casual use. Picking a random winner for a giveaway, choosing which movie to watch, or settling a friendly argument with a coin flip — Math.random() is entirely adequate. The Mersenne Twister has a period of 219937−1. Nobody is going to replay enough of your coin flips to break it.
What matters more for fairness in everyday use is often process transparency, not algorithmic strength — a point explored in detail in the companion article on randomness and fairness. The perceived legitimacy of a random outcome often has more to do with how the process was conducted than with the statistical quality of the numbers themselves.
The next time you press "randomize" on something, though, it's worth appreciating the small miracle happening: your machine, an entirely deterministic device, is doing its best impression of something it can never truly be — genuinely unpredictable. And for most purposes, it's a pretty convincing performance.