How Online Coin Flippers Work

A short, technical walkthrough of what's actually happening when you click "Flip" — and what to look for if you want to know whether a coin-flip site is fair.

Last reviewed: April 25, 2026

The whole pipeline, in one sentence

An online coin flipper takes a random number from somewhere, reduces it to one of two outcomes, optionally plays an animation, and shows you the result. Almost every interesting question — is it fair? can it be predicted? does the animation match the result? — is really a question about the "from somewhere" step.

Where the random number comes from

There are roughly four sources a website might use:

1. Math.random() — the easy, weak choice

The classic JavaScript function. It's a pseudo-random number generator (PRNG) seeded by the browser at startup. Math.random is fast, available everywhere, and good enough for things like deciding which background image to show. It is not designed to be unpredictable, and historically some browsers used PRNG algorithms with detectable statistical bias.

For a coin flip done casually, Math.random is fine in practice — the bias is tiny and no one is trying to predict the next outcome. But if a site uses it and claims "cryptographically secure" randomness in marketing, that's a contradiction.

2. crypto.getRandomValues — the strong, modern choice

Part of the Web Crypto API, available in every modern browser. It's a cryptographically secure pseudo-random number generator (CSPRNG) — meaning that even with full knowledge of past outputs, you cannot predict the next one. It's the same family of randomness used to generate session tokens, encryption keys, and password salts.

This is what the Coin Toss Simulator uses. The whole flip routine is essentially:

const buffer = new Uint32Array(1);
crypto.getRandomValues(buffer);
const outcome = buffer[0] % 2 === 0 ? 'heads' : 'tails';

That's it. The number you get is a uniformly distributed 32-bit unsigned integer; checking even/odd splits the integer space exactly in half, so the mapping introduces no bias.

3. Server-side randomness

Some flippers call back to a server, generate the result there, and return it. This isn't inherently better or worse than client-side generation. A reputable server can use a strong CSPRNG or even hardware randomness (more on that below). But you, as the visitor, have no way to verify any of it from the outside — you have to trust the site.

4. Hardware randomness

"True" random number generators sample physical noise — atmospheric noise, radioactive decay, the timing jitter of electronic components — and hash it into bits. Services like random.org operate this way. For a casual coin flip the practical difference between hardware randomness and a good CSPRNG is undetectable. For regulated gambling or cryptography, it matters.

The animation problem

One question worth asking of any coin-flip site: is the animation rigged to match a pre-decided result, or does the animation drive the outcome?

Almost always, it's the first. The result is decided the instant you click; the animation is then choreographed to land on that face. This is fine — and how the Coin Toss Simulator works — provided the result was decided by a real source of randomness. If, instead, the site rolls the result after watching how you interact (mouse movement, click timing), that opens the door to the result being influenced by something other than chance. You can't see the difference from the outside.

How to tell if a flipper is fair

Without source code you can't be certain, but a few heuristics help:

  • View the page source. If you see crypto.getRandomValues, the site is using the strong source. If you see Math.random(), it's using the weak one. If you see neither, the result is probably coming from a server.
  • Check what's stored. Open your browser's storage panel. A page that uses localStorage only for stats and preferences (and no cookies tying you to a session) almost certainly isn't running anything weird with the result.
  • Run a sanity test. Flip 1,000 times and look at the heads percentage. Anywhere from about 47% to 53% is well within normal variation; numbers far outside that range, repeatedly, are suspicious. The law of large numbers page covers what "normal variation" looks like.
  • Be wary of "100% truly random" claims that don't say how. Marketing copy is not evidence. A short sentence about which API is used is.

Why CSPRNG vs PRNG matters in practice

For a single coin flip — a friend choosing who pays for coffee — the difference is academic. For anything sequential, predictable pseudo-randomness becomes a problem. If a website used Math.random with a known seed for a tournament bracket draw, an adversary could in principle reproduce the entire bracket. The same risk doesn't apply to a one-off flip, which is why the relaxed standard is common, but it's also why we default to the strong source: it costs nothing extra and removes a class of question entirely.

What about "cryptographically secure" claims?

That phrase has a specific meaning: a CSPRNG must pass next-bit and state-compromise tests — informally, "given everything you've seen so far, you can't guess what comes next better than chance, and you can't recover the internal state from the outputs." A handful of well-vetted algorithms qualify. Browsers' Web Crypto implementations use such algorithms; Math.random implementations do not.

Read next