True Randomness vs Pseudo-Randomness: Why It Matters for Code Generation

Every programming language has a built-in way to generate a random number, and for most everyday purposes it works perfectly well. Shuffle a deck of cards in a game, pick a random background colour, roll a virtual die, none of it needs to survive an actual attack. The moment randomness protects something valuable though, a password, a gift card balance, a session that proves who you are, the everyday kind of random stops being good enough, and most people generating codes have never had a reason to learn why.

What is pseudo-random number generation actually doing?

A pseudo-random number generator, the kind behind a typical Math.random() call, is a mathematical formula that produces a sequence of numbers which look statistically random, evenly distributed, no obvious pattern, but are entirely determined by an initial starting value called a seed. Feed the same seed into the same algorithm twice and you get the exact same sequence of "random" numbers both times. That's not a flaw for most applications, it's often a useful feature, letting a game replay the same random level from a shared seed, for instance. But it means that if an attacker can work out or guess the seed and the algorithm, the entire sequence becomes predictable.

Where does cryptographically secure randomness actually come from?

Cryptographically secure random number generation takes a fundamentally different approach. Rather than starting from a single seed and running a predictable formula, it draws from an entropy pool built up by the operating system out of genuinely hard-to-predict physical events: the precise microsecond timing between keystrokes, small variations in disk read times, mouse movement jitter, and on many modern processors, dedicated hardware that generates randomness from electrical noise. This entropy feeds a cryptographic pool that JavaScript's crypto.getRandomValues() and equivalent server-side functions draw from, and it's specifically engineered so that even someone who fully understands the algorithm cannot predict future output from past output.

Why can't you just tell by looking at the output?

This is the part that trips people up: a sequence produced by Math.random() and a sequence produced by crypto.getRandomValues() can look identically random to a human being staring at them. Both pass basic statistical randomness tests. The difference isn't in how the output looks, it's in whether a sophisticated attacker who studies the algorithm and gathers enough samples could, in principle, predict what comes next. For rolling dice in a mobile game, that theoretical predictability doesn't matter to anyone. For generating a password reset token, it matters enormously, because predictability is exactly what an attacker is trying to find.

Does this actually matter for the codes you generate day to day?

It depends entirely on what the code protects. A one-off code for a small office raffle or a fun giveaway carries essentially no risk even if it were generated with ordinary pseudo-random logic, because there's nothing meaningfully at stake if someone predicted it. A password, an API key, a session token, a gift card code representing real stored value, all of these deserve cryptographically secure randomness without question, because predictability there is a genuine security failure, not a theoretical curiosity.

How does this site generate codes?

The generator on this site uses the browser's built-in cryptographically secure random source rather than a general-purpose random function, for exactly the reasons above, and everything happens locally in your browser with nothing transmitted anywhere. Whether you're generating a password, an API key, or a batch of voucher codes, the underlying randomness is the same cryptographic quality regardless of what you're using it for.