Are Online Dice Rollers Truly Random? How RNGs Actually Work

There's a moment every tabletop gamer knows: you're deep in a campaign, the rogue is attempting a critical pickpocket, and someone at the table pulls up an online dice roller instead of reaching for physical dice. And then, inevitably, someone else mutters, "Is that thing actually random though?"

It's a fair question — and the honest answer is: it depends entirely on which dice roller you're using and what's generating the numbers under the hood.

Let's get into the actual mechanics, because this rabbit hole is deeper than most people expect, and understanding it will make you a better judge of which tools are trustworthy for your games.

The Fundamental Problem With "Random" on a Computer

Computers are deterministic machines. Feed them the same inputs, run the same program, and they produce the same outputs — every time. This is the bedrock of reliable software. But it also means that true randomness, in the purest sense, is fundamentally alien to what computers do.

So how do dice rollers generate numbers that seem random? Most of them use what's called a Pseudo-Random Number Generator, or PRNG. A PRNG is an algorithm that takes a starting value — called a seed — and uses mathematical operations to produce a sequence of numbers that passes statistical tests for randomness. The sequence looks random. It behaves statistically like random. But it isn't random. It's entirely deterministic. If you knew the seed, you could predict every number the generator would ever produce.

The most famous PRNG in everyday use is the Mersenne Twister, developed in 1997 by Makoto Matsumoto and Takuji Nishimura. It produces sequences with a period of 2^19937 − 1, meaning it cycles through that many numbers before repeating. For context, that's a number with about 6,000 digits. For generating dice rolls in your D&D session, this is fine. More than fine, actually — the statistical properties are excellent.

But here's the catch: the Mersenne Twister is seeded. And in many early (and still some modern) implementations, that seed comes from something like the current system timestamp in milliseconds. If two people opened the same dice roller at the same millisecond, they'd get the same sequence of rolls. That's not a hypothetical — it's been exploited in real gambling applications.

How Most Browser Dice Rollers Actually Work

When you open a basic dice roller in a browser and click "Roll," the JavaScript engine is almost certainly calling Math.random(). This is a PRNG built into the browser. In modern V8 (the engine behind Chrome and Node.js), Math.random() uses an algorithm called xorshift128+, which is fast, has decent statistical properties, and is seeded with entropy pulled from the operating system.

xorshift128+ is a significant step up from naive timestamp-seeded generators. The V8 team switched to it around 2015 specifically because the older implementation failed certain randomness tests. Still, it's worth knowing what you're getting: a PRNG seeded with OS entropy, not something cryptographically secure.

For rolling dice in a board game, a PRNG with good statistical properties is genuinely sufficient. The distribution across faces will be even over enough rolls. There's no detectable bias. No one is going to reverse-engineer your tabletop dice rolls from xorshift128+.

The place where this matters more is high-stakes contexts: online poker, lottery draws, anything where someone has a financial incentive to predict outcomes.

Cryptographic RNGs: A Different Beast Entirely

Enter the Cryptographically Secure Pseudo-Random Number Generator, or CSPRNG. The key distinction from a regular PRNG is unpredictability — even if an attacker knows the algorithm and observes a long sequence of outputs, they cannot predict the next value. This is a hard mathematical guarantee, not just a statistical one.

CSPRNGs draw their entropy from sources that are genuinely difficult to predict: hardware interrupts, thermal noise in CPU circuitry, keyboard and mouse timing variations, network packet arrival jitter. Linux collects this into a kernel entropy pool and exposes it via /dev/urandom and the getrandom() syscall. Windows has BCryptGenRandom. macOS uses SecRandomCopyBytes.

In browser JavaScript, the equivalent is crypto.getRandomValues() — part of the Web Cryptography API. Any dice roller that uses this instead of Math.random() is operating in a fundamentally different security tier. The numbers are seeded with actual system entropy, and the implementation meets cryptographic standards.

RANDOM.ORG takes a different approach entirely: they generate randomness from atmospheric noise — actual physical radioactive-decay-like unpredictability from the real world, served over an API. If you need randomness that has no algorithmic component whatsoever, that's your tool.

Does This Actually Matter for Tabletop Gaming?

Here's where I'll give you a practical answer rather than a theoretical one: for the vast majority of tabletop gaming contexts, a well-implemented PRNG is completely fine.

Consider what "unfair" would actually mean for a digital dice roll in your Pathfinder session. For a result to be meaningfully unfair, someone would need to:

1. Know the algorithm and seed
2. Track the sequence of previous rolls to establish state
3. Predict the next roll with enough accuracy to act on that knowledge

In practice, this isn't happening at your game table. The seeds are derived from OS entropy. The state after even a few dozen rolls is computationally infeasible to recover from the outputs alone (for xorshift128+, the full state is technically recoverable from about 64 outputs, but doing this in real-time during a game session isn't realistic).

Where the distinction genuinely matters is in competitive contexts. Online tournaments, organized play where stakes are meaningful, or any scenario where a roll can be audited or contested later — these are cases where you want a CSPRNG or, better, a verifiable external randomness source with a public audit trail.

The Variance Problem Nobody Talks About

There's a separate issue that matters more to tabletop gamers than PRNG vs CSPRNG: short-run variance. Any random number generator — whether it's a physical die, a Mersenne Twister, or the best CSPRNG on earth — will produce streaks. Rolling three 20s in a row is not evidence of tampering. Rolling no 20s in 50 rolls is not evidence of bias. These things happen.

Physical dice have their own bias problems, incidentally. Casino dice are precision machined to tolerances of 1/10,000th of an inch because standard dice are measurably unfair. The pips drilled into each face remove material, making each face weighted differently. A 6-face has more material removed than a 1-face, so there's a very slight bias toward rolling lower on cheap plastic dice. Digital dice rollers, if properly implemented, have no such mechanical bias.

The irony is that players often perceive digital dice as less fair precisely because they don't have the physical ritual of rolling. The psychology of randomness is fascinating: we trust what we can touch.

How to Evaluate a Dice Roller You're Actually Using

If you want to know whether a specific tool is trustworthy, here's what to look for:

Check if it uses the Web Crypto API. If the tool's source code is available (many simple dice rollers are open source), search for crypto.getRandomValues. If you see Math.random() without the Web Crypto API, you're getting a basic PRNG. Not bad, just not cryptographically secure.

Look for provable fairness. Some implementations offer commitment schemes — before generating a number, they hash their internal seed state and publish that hash. After the roll, they reveal the seed, and you can verify the hash matches. This proves the number wasn't chosen after the fact. Roll20 and some online card game platforms use variants of this approach.

Run a quick Chi-squared test. Roll 600 times on a d6. Each face should appear roughly 100 times. If one face appears 200 times and another appears 20 times, something is wrong. In practice, a few dozen rolls off-mean is expected. But gross deviation over hundreds of rolls indicates a bug.

For high-stakes use, go external. RANDOM.ORG's dice roller, ANU Quantum Random Numbers (which uses quantum vacuum fluctuations — genuinely as random as physics allows), or any implementation backed by a hardware security module will exceed anything you actually need for gaming purposes.

The Bottom Line

Online dice rollers are not random in the strict mathematical sense — almost nothing digital is. But the good ones produce sequences that are statistically indistinguishable from true randomness, are seeded with genuine system entropy, and will not be predicted or manipulated in any practical tabletop gaming scenario.

The best consumer dice rollers (anything using crypto.getRandomValues() or an equivalent OS-level CSPRNG) are actually fairer than physical dice, which carry measurable mechanical biases from manufacturing.

If you're running a casual campaign, use whatever dice roller feels good. If you're running a high-stakes tournament or someone's money is involved, use a CSPRNG-backed tool with a public audit log, or better yet, use RANDOM.ORG's API with logging enabled so results can be independently verified.

The real problem at your game table probably isn't RNG quality. It's that the rogue keeps rolling 20s when anyone else would fail, and no algorithm is going to explain that.