Understanding the Random Generator Algorithms Behind Online Dice Tools

The animation is a playback, not the roll

Everything you see when you press a roll button happens after the outcome is already decided. A well-built roller generates the values, stores them, and then runs an animation that ends by displaying what it already has. The tumble is a presentation layer placed on top of a completed calculation.

That ordering is not a detail of implementation style. It is the property that makes the tool trustworthy: if the result were computed at the end of the animation, the animation's duration and the moment you stopped it would become inputs to the roll.

So the interesting question is not what the animation does but which random source feeds the calculation behind it — and browsers give you three very different answers.

Three sources of randomness, ranked

The middle row is where most home-made rollers live, and the failure mode is subtler than "it is not random". Math.random() in a modern JavaScript engine is a well-specified algorithm — in V8 it is a variant of xorshift128+, a generator with 128 bits of state. Its output passes ordinary statistical tests, so a program that checks for an even distribution over a million rolls will find one. The problem is different: because the algorithm is public and the state is finite, a small number of consecutive outputs is enough to reconstruct the state and predict every subsequent value. A dice roller has no adversary in most cases, so this rarely matters — but for anything with a prize attached, it is the difference between fair and merely even-looking.

The cryptographic path, and the bias that comes with it

A CSPRNG hands you uniform 32-bit integers. Turning one into a die face requires a mapping, and the obvious mapping has a flaw that is worth understanding precisely because it is usually described as a serious problem when it is not.

The mapping used here is floor(random × sides) + 1, where the random value is uniform from 0 up to but not including 1. A 32-bit source has exactly 4,294,967,296 possible values, and no number of die faces divides that evenly, so some faces must be reachable by more source values than others.

The size of that imbalance depends on the die:

A game would need on the order of hundreds of millions of rolls to have any hope of detecting that skew, and the underlying entropy would be exhausted long before the statistics converged. The right conclusion is not that modulo bias is harmless in general — with a small source range such as 8 bits it becomes severe and obviously exploitable — but that pairing a 32-bit cryptographic source with a twenty-sided die puts it roughly seven orders of magnitude below the noise floor.

Seeds, reproducibility and what they are for

A pseudo-random generator is defined by an algorithm plus a starting state, called a seed. Give the same seed to the same algorithm and you get the same sequence, every time, on every machine. A tool that accepts a seed is not offering less randomness; it is offering repeatability, which is a different feature.

Seedable rolls exist for verification. If two people need to confirm that they made the same rolls — a tournament ruling, a provably fair scheme, a shared replay — a seed plus an agreed algorithm is the only way to reproduce the sequence without exchanging the results. Note what a seed does not provide: it does not make the rolls unpredictable to a third party who does not know the seed only if the seed has enough entropy itself. A seed of "1" is reproducible by anyone.

The full pipeline, in order

• You press roll. The click handler runs.
• For each die in the pool, one 32-bit value is drawn from the cryptographic source and mapped to a face. The complete array of results now exists.
• The tray is cleared and placeholder dice are rendered, each showing a value produced by additional draws.
• A timer updates those placeholder faces on a fixed interval, roughly every 120 milliseconds, for about five frames.
• The timer stops and, after a short delay, the tray is replaced with the real values. The total is summed and the roll is appended to the session log with a timestamp.

At no point after step two does anything influence the result. The animation's only job is to make the moment feel like a roll rather than a lookup.

What "fair" can and cannot mean in a browser

A browser roller can be verifiably unbiased in its arithmetic, and it can be immune to prediction. What it cannot do is prove to you, from the outside, that the code you loaded is the code that ran. Anyone can serve a modified script, and a roller that is fair in principle can be dishonest in delivery.

That limits what a claim of fairness is worth, and it points to the checks that are actually useful:

• Can you read the random source? A one-line implementation is auditable; an obfuscated bundle is not.
• Does the result exist before the animation? The roll should be complete on click, not on animation end.
• Is the die range derived from the input rather than from a table of allowed results? A list of permitted outcomes is a red flag.
• Is a seed optional, and is it labeled as a reproducibility feature rather than as an entropy source?
• Does the history record the individual faces as well as the total, so the arithmetic can be checked?

For a tabletop game, a cryptographic source mapped through a full-range multiply is more rigour than the situation requires, and it costs nothing. For anything with money or status attached, no client-side roller is sufficient on its own — the fairness has to be provable to a third party, which usually means a published algorithm and a committed seed rather than a promise about a script.