Coin Flip Simulator

Introduction to the Bernoulli trial behind every flip

A single coin flip is the textbook Bernoulli trial: one experiment, two mutually exclusive outcomes, a fixed probability attached to each. Write p for the probability of heads. Then the probability of tails is q = 1 − p, and for the idealised fair coin used by default here:

Formula: P(Heads) = p = 0.5, P(Tails) = q = 1 − p = 0.5

Two properties define the model and both matter for interpreting your results. First, the trials are independent: the outcome of flip 37 carries no information about flip 38, so no run of heads makes tails “due”. Second, the trials are identically distributed: the same p applies to every flip in the batch, because the simulated coin does not wear out, warm up or learn.

Those two assumptions are what let the whole batch be summarised by a single number, the head count X, and let that count be described by one distribution instead of an unmanageable list of 2ⁿ possible sequences.

How to use the flip count, bias slider and random source

All of the controls sit in one row above the coin. Each one changes the statistics that come back, so it is worth knowing what each does.

1. Number of flips (n). Any whole number from 1 to 100,000. The NIST tests reported below the result only become meaningful at n ≥ 100, which is the minimum sequence length recommended in SP 800-22 sections 2.1.7 and 2.3.7; below that the page still reports them but flags them as under-powered.
2. Probability of heads (p). A slider from 0.00 to 1.00 in steps of 0.01. Leave it at 0.50 for a fair coin. Move it to 0.51 to model the same-side bias measured for real physical tosses, or drag it to an extreme to watch how quickly a small bias becomes detectable as n grows.
3. Random source. crypto.getRandomValues is the default. It is the Web Crypto pseudorandom generator, seeded with operating-system entropy and considered suitable for cryptographic use. Math.random() is the plain ECMAScript generator, which is explicitly not cryptographically secure. Switch between them and run a few thousand flips each way to see that both pass the monobit test comfortably — passing a fairness test is a much lower bar than being unpredictable.
4. Flip the coin. Press the button, press Enter or Space while the coin canvas has keyboard focus, or tap the coin itself.
5. Read the result panel. The metric tiles give counts and shares; the table below them gives the inferential statistics; the distribution chart shows where your batch landed inside the binomial distribution it was drawn from.
6. Export. Copy the summary text, download every individual flip as CSV for a spreadsheet or a class exercise, or copy a permalink that restores n, p and the random source. The permalink restores settings, not results: the sequence is not seeded, so it can never be reproduced.
7. Reset. Returns every control to its default, clears the result and clears the chart.

The binomial formula that grades your batch

Let X be the number of heads in n independent flips, each with probability p of heads. Then X follows the binomial distribution, whose probability mass function NIST gives as:

Formula: P(X = k) = (n / k) p^k (1−p)^n−k, k = 0, 1, …, n

The binomial coefficient counts the sequences, and the power terms give the probability of any one of them:

Formula: (n / k) = (n !) / (k !(n − k) !)

The two summary numbers printed in the result tiles come straight from the same NIST handbook page. The expected head count and the standard deviation of the head count are:

Formula: μ = n p, σ = sqrt(n p(1 − p)) = sqrt(n p q)

From those the page reports a standardised distance, which tells you how unusual your head count is in units of standard deviation:

Formula: z = (k − n p) / (sqrt(n p(1 − p)))

Note that σ grows with the square root of n while μ grows linearly. That single fact is the whole reason the proportion of heads stabilises while the raw gap between heads and tails does not. For a fair coin, the expected absolute gap between heads and tails after n flips is approximately √(2n/π): about 8 after 100 flips, about 80 after 10,000 flips. The gap gets bigger, the share gets steadier.

To decide whether the observed share is compatible with a stated p, the page reports the Wilson score interval, which NIST recommends over the textbook normal interval because it does not misbehave when the count is near 0 or n:

Formula: CI = (p^+ z^2 / (2 n) ± z sqrt((p^(1 − p^)) / n + z^2 / (4 n^2))) / (1 + z^2 / n)

with z = 1.95996 for a two-sided 95% interval. If that interval contains the probability you set, your batch gives no evidence against it.

Worked example: 100 flips that came back 58 heads

Suppose you leave p at 0.50, set n to 100, and the run returns 58 heads and 42 tails. Is that a suspicious coin?

1. Expected count. μ = np = 100 × 0.5 = 50 heads.
2. Standard deviation. σ = √(100 × 0.5 × 0.5) = √25 = 5 heads.
3. Standardised distance. z = (58 − 50) / 5 = 1.60. The result is 1.6 standard deviations high — noticeable, not remarkable.
4. Exact point probability. P(X = 58) = C(100, 58) × 2⁻¹⁰⁰ = 2.229%. Every individual count is rare when there are 101 of them; this on its own proves nothing.
5. Exact two-sided tail probability. P(|X − 50| ≥ 8) = 2 × P(X ≥ 58) = 2 × 0.06661 = 0.1332. A fair coin produces a result at least this lopsided about 13 times in 100 batches.
6. NIST monobit test. Convert to ±1: S_n = 2 × 58 − 100 = 16, so s_obs = 16 / √100 = 1.6 and the p-value is erfc(1.6 / √2) = 0.1096. Because 0.1096 ≥ 0.01, the sequence passes at the 1% level.
7. Wilson 95% interval. With p̂ = 0.58 and n = 100 the interval is 0.4821 to 0.6720. It comfortably contains 0.50.

The conclusion is that 58 heads in 100 flips is entirely ordinary. Notice also the gap between the exact tail probability (0.1332) and the normal-approximation monobit p-value (0.1096): at n = 100 the normal approximation is already usable but not exact, which is precisely why SP 800-22 recommends at least 100 bits and why the page reports the exact binomial figure alongside it.

Now change one thing. Keep 58% heads but flip 10,000 times instead of 100, giving 5,800 heads. Then σ = √2500 = 50, so z = (5800 − 5000) / 50 = 16, and the monobit p-value collapses to something far below 10⁻⁵⁰. The same share of heads is unremarkable in 100 flips and overwhelming evidence of bias in 10,000. Sample size, not the percentage, is what turns an observation into evidence.

Reading the randomness report: monobit, runs and streaks

Below the metric tiles the page reports two tests taken directly from NIST SP 800-22. Both return a p-value and both use the same decision rule: a p-value below 0.01 means the sequence is declared non-random at the 1% level.

The frequency (monobit) test asks only whether the count of ones is close enough to half. Mapping heads to 1 and tails to 0, it computes:

Formula: S_n = ∑ i = 1 n(2 ε_i − 1), s_obs = (| S_n |) / sqrt(n), P = erfc (s_obs / sqrt(2))

The runs test asks a different question: not how many heads there were, but how often the sequence switched. A run is an uninterrupted block of identical outcomes, and V_n(obs) counts them. Too few runs means the sequence sticks (long streaks); too many means it alternates unnaturally fast. NIST first requires the sequence to pass a frequency screen, |π − ½| < τ with τ = 2/√n, and only then computes:

Formula: P = erfc ((| V_n(obs) − 2 n π(1 − π) |) / (2 sqrt(2 n) π(1 − π)))

The report also gives your longest streak and the exact probability that a fair sequence of the same length contains a streak at least that long. That probability is computed from an elementary recursion rather than a rule of thumb: the number of binary strings of length m whose runs are all shorter than L is twice the number of compositions of m into parts of size at most L − 1, so with C(0) = 1,

Formula: C(m) = ∑ j = 1 L − 1 C(m − j), P(longest run < L) = (2 C(n)) / 2^n

The numbers this produces are the antidote to streak superstition. In 100 fair flips there is a 97.2% chance of a run of at least 5, an 80.7% chance of a run of at least 6 and a 54.2% chance of a run of at least 7. A streak of six is not a sign of a rigged coin; its absence would be the surprise.

Reference probability table for common coin questions

Every figure below is for a fair coin with p = 0.5 and is computed exactly, not rounded from a simulation.

Read the last three rows carefully, because they are the ones people get wrong. A ten-heads streak has probability 1 in 1024 at a specified position, but across 1,000 flips there are hundreds of positions where such a streak could start, so seeing one is more likely than not.

Where a virtual toss fits, and its limitations

The table below sets out what this tool is and is not suitable for. The unsuitable rows are not disclaimers for their own sake; each one names a specific property the simulator lacks.

Beyond those use cases, four assumptions and limitations apply to every number this page reports:

• The generator is pseudorandom, not random. Both sources are deterministic algorithms driven by a hidden state. crypto.getRandomValues is seeded with operating-system entropy and is considered unpredictable in practice; Math.random() is not, and its algorithm is left entirely to the JavaScript engine by ECMA-262.
• Passing a randomness test is not proof of randomness. The monobit and runs tests can only fail a sequence, never certify one. The fixed sequence HTHTHTHT… passes the monobit test perfectly while being completely predictable, which is why SP 800-22 contains fifteen tests rather than one.
• The tests are asymptotic. Both p-values rest on normal approximations that SP 800-22 recommends applying only when n ≥ 100. Below that they are reported for continuity but should not be used to accuse a coin of anything.
• Nothing is reproducible. No seed is exposed, and the permalink stores only your settings. If you need the same sequence twice, implement a seeded generator in your own code.

Sources