Methodology & Accuracy

A coin toss is only worth anything if both parties trust the mechanism, so here is the whole mechanism. This page documents where the randomness comes from, the exact order in which things happen when you press Toss, what the animation is permitted to influence (nothing), and how each of those claims is pinned by an automated test.

The entropy source

Random bytes come from crypto.getRandomValues, the browser's cryptographically strong random source, which is seeded with entropy gathered by your operating system. It is notMath.random, which is a fast pseudorandom generator with no security guarantees and a state that can, in principle, be inferred from its output. Nothing here needs cryptographic strength to settle who buys coffee, but using the strong source costs nothing and removes an entire category of question.

Rejection sampling, not modulo

To turn random bytes into a number in a range, the engine takes the minimum number of bits that covers the range, masks off the excess, and — the step that matters — discards any draw that lands at or beyond the range and draws again. The tempting shortcut,randomByte % range, quietly favors low values whenever the range does not divide the byte range evenly.

For a coin, span two, modulo would in fact be harmless: 256 divides evenly by 2. The engine does it properly anyway, because the same routine also draws the flight length from a span of five, where modulo would not be harmless — and because a randomness primitive that is only correct for convenient spans is a trap waiting for the next feature.

The order of operations

Pressing Toss runs three steps, in this order:

1. The engine draws one uniformly random bit and maps it to heads or tails. This is the outcome. It is now fixed.
2. The engine computes the flight: a number of half-turns whose parity is whatever makes the coin land on the face already drawn, plus an independently drawn number of extra half-turn pairs so that no two tosses look identical. It returns the exact final rotation.
3. The animation runs, decelerating onto that rotation.

Because flight length is drawn independently of the face, a long tumble carries no information about how it will land. And because a pair of half-turns returns the coin to the face it launched from, the parity rule is all that is needed to guarantee the landing shows the drawn face — an invariant the tests check for both faces, every flight length, and every starting orientation.

Why not simulate the physics

Simulating a tumbling disc and reading whichever face ends up on top sounds like the more honest approach. It is the less honest one. The result would then depend on floating-point arithmetic, frame timing, and whatever constants the author happened to pick, and the bias of that combination is unknown, unmeasured, and would differ between devices. A drawn-first coin has a bias you can reason about: zero, by construction, from a source with a specification. The animation is presentation, and saying so plainly is the point.

Calling before the flip, and calling in the air

Both call modes are recorded, never consulted. The face is already drawn before either kind of call is possible, and the call is stored alongside it purely so the tally can tell you how often you were right. A called toss and an uncalled toss run through identical code. This is also why calling in the air is honest here for exactly the reason it is honest with a real coin: by the time the coin is up, the outcome is already determined and you cannot see it.

What the tally counts

Heads, tails, total tosses, your longest run of a single face, and — when you have called — how many calls matched. The longest run is there deliberately: streaks are the most common reason people suspect a coin is broken, and a fair coin produces them constantly. Six of one face in a row is about a 1-in-64 event and will show up regularly in a long session. The tally is computed by a tested function rather than tracked ad hoc in the interface, because a tally that drifts is exactly what makes a fair tool look rigged.

Real coins, for comparison

Physical coin tosses carry a small same-side bias: a tossed coin precesses rather than turning cleanly about one axis, so the face that starts up lands up slightly more often than half the time. Large-scale empirical work — including a study in which volunteers recorded hundreds of thousands of real flips — puts the effect on the order of a percent, which is far too small to notice by hand and far too small to matter for everyday decisions, but it is measurable and it is real. This coin has no launch face, so there is nothing for that bias to attach to.

Accessibility and reduced motion

The result is announced as text in a live region, and the coin graphic itself is hidden from assistive technology — a screen reader gets "Tails", not a description of a tumbling disc. If your system requests reduced motion, the flight is skipped entirely and the coin simply shows the drawn face. Call-it-in-the-air still works in that mode: the coin waits for your call without animating, because the call window is part of the interaction, not part of the animation.

Where the site stops

This is a toy in the precise sense: fair enough for tie-breaks and games, not a certified or auditable randomness source. There is no record anyone else can verify afterwards, because nothing is stored anywhere but your own browser. If a decision must be provable to a third party, you need a documented procedure with an audit trail, and no web page can supply that. If you believe a result here is wrong, the contact page is the right place — confirmed issues get fixed in the engine and locked in with a new test.