Simulate thousands of coin flips and watch the heads proportion converge to 50% in real time. A live law-of-large-numbers demo for stats class.
This is a Monte Carlo coin-flip experiment, not a single toss. You pick how many trials to run — 10, 100, 1,000, 10,000 or 100,000 — press Run, and the page flips that many times in the browser while two charts update live: a bar chart of the observed heads/tails split against the expected 50/50, and a line showing the running proportion of heads creeping toward the 50% target. If all you want is one toss to settle an argument, the plain coin flip page is the faster door; this page exists to show you why that toss averages out.
Skip position that finishes the remaining trials in a single frame. At 1× you see individual flips; at Skip a 100,000-trial run is over before you lift your finger.Six numbers sit above the charts and update continuously: trials completed out of the target, observed P(Heads), expected (a fixed 50.00%), absolute deviation between the two, current streak and longest streak. One honest detail about the streak counters — they count consecutive heads only. A tail resets the current streak to zero rather than starting a tails streak, so "longest streak: 11" means eleven heads in a row, not eleven of the same face.
This is the single most misunderstood thing about coin flipping, and running the simulator at both 100 and 100,000 trials makes it obvious. The proportion of heads converges on 50%. The absolute difference between the number of heads and the number of tails does the opposite: it drifts steadily further from zero.
Both facts come from the same place. The standard deviation of the head count over n flips is √n / 2, so the standard deviation of the head–tail gap is √n, and the typical size of that gap is about 0.798 × √n. Divide the gap by n to get a proportion and the √n is overwhelmed by the n — which is why the percentage tightens up while the raw gap widens.
| Trials | Std. error of P(Heads) | Typical heads–tails gap | Typical deviation from 50% |
|---|---|---|---|
| 10 | 15.8% | about 2.5 | about 12.6 points |
| 100 | 5.0% | about 8 | about 4.0 points |
| 1,000 | 1.58% | about 25 | about 1.3 points |
| 10,000 | 0.50% | about 80 | about 0.4 points |
| 100,000 | 0.158% | about 252 | about 0.13 points |
Read the third and fourth columns together. Going from 100 trials to 100,000 makes the gap roughly thirty times bigger in absolute terms and roughly thirty times smaller as a percentage. Watch the "Abs. deviation" readout during a 100k run and you will see it behave exactly this way: it does not march smoothly to zero, it wanders and shrinks in fits.
The law of large numbers is the formal version of that first column. It promises the proportion converges on the true probability; it promises nothing at all about the running total balancing out. There is no force pulling a coin back toward parity. A run that is 60 heads ahead does not get corrected — it gets diluted.
The upper chart is the outcome distribution: solid bars for what the simulator actually observed, and a dashed red rectangle drawn at the theoretical height for each outcome. With a fair coin the two dashed boxes both sit at 50%, and the interesting thing is watching the solid bars grow toward them. At 10 trials the bars are frequently nowhere near the dashes. By 10,000 the mismatch is usually invisible at chart resolution.
The lower chart is the running proportion of heads across the whole run, with a dashed horizontal line at the 50% target. Its shape is the lesson: violently jagged on the left, almost flat on the right. That is not the coin becoming fairer — it is the denominator growing. Early on, one flip can move the proportion by tens of points; at trial 90,000, one flip moves it by about 0.0006 points.
To keep the drawing fast at high trial counts, the line is sampled at a fixed stride rather than plotting every flip — roughly 420 points across a run, whatever its length. Every flip still counts toward the statistics; only the line's plotted resolution is capped.
The complaint the streak counter is built to answer is "I got eight heads in a row, this can't be random." Eight in a row has probability 1/2⁸ = 1/256 starting at any given flip. In a thousand-flip run there are hundreds of places for such a streak to begin, so seeing one is unremarkable. The rough rule is that the longest head run in n flips is around log₂(n): about 7 in 100 flips, about 10 in 1,000, about 13 in 10,000, about 17 in 100,000.
Run the simulator at 10,000 with the speed slider low enough to watch, and the "longest streak" number climbing into double digits is the expected outcome. A sequence with no long runs is the suspicious one — hand-written "random" sequences almost always alternate too much, because people avoid writing HHHHHHH.
Set Runs to 1k and run it a few times. Expected heads is 500; the standard deviation of the head count is √1000 / 2 = 15.81. About 95% of runs land within roughly two standard deviations, so a head count between about 469 and 531 — observed P(Heads) between 46.9% and 53.1% — is ordinary. A run that gives 512 heads is not a biased coin; it is 0.76 standard deviations from centre, which happens most of the time.
Compare that to a 10-flip run, where the same 95% band spans roughly 2 to 8 heads. Getting 8 heads out of 10 looks dramatic and means nothing. Getting 8,000 heads out of 10,000 would be a different universe. Small samples are not a weak version of large samples; they are qualitatively uninformative, and flipping the Runs selector between 10 and 10k is the fastest way to feel that.
One more number worth having: exactly 5 heads in 10 flips — the "expected" result — happens only 252/1024 = 24.6% of the time. The most likely single outcome is still a minority outcome. That is why "it didn't come out 50/50" is never by itself an argument about fairness.
Each trial calls the suite's flip() function, which draws from the browser's built-in Math.random() and returns Heads below 0.5 and Tails otherwise. That is a fast pseudorandom generator, seeded by the browser and perfectly adequate for demonstrating convergence, teaching probability, or any casual decision. It is not a cryptographic source — the tool does not use crypto.getRandomValues — so do not use these results to generate keys, tokens, lottery entries, or anything where an adversary predicting the sequence would matter.
For the statistics on this page the distinction is academic: Math.random() is uniform enough that 100,000 trials will not distinguish it from a fair coin. For key material it is disqualifying. Both things are true at once.
Every flip happens in your browser. There is no request to a server for random numbers, no results posted anywhere, and no account needed. That has a practical consequence beyond privacy: the simulator works with the network off, and a 100,000-trial run costs no round trips, which is why it can finish in one frame on the Skip speed. Refreshing the page discards the run — results are held in memory only.
inventivehq.com line along the bottom. Useful for lecture slides, lab reports and homework where you need to show the run you actually did rather than a stock textbook curve.<iframe> snippet pointing at this simulator on your clipboard, sized 640×520 with lazy loading, ready to paste into a lesson page or blog post.Is the coin actually fair? Yes — the threshold is exactly 0.5, with no weighting option. There is no setting for a biased coin on this page.
Why is my observed percentage not moving toward 50% smoothly? Because convergence is not monotone. The running proportion is allowed to move away from 50% at any point; it simply becomes less able to move far as the trial count grows. Expect the line to wobble across the target rather than approach it from one side.
Can I run more than 100,000 trials? Not from the presets — 100k is the ceiling, chosen so a run stays responsive in the browser. At that size the standard error is already about 0.158%, small enough that more trials change nothing you can see on the chart.
Does "Step" affect the statistics differently from "Run"? No. Stepping performs one trial through exactly the same code path the animation loop uses. Speed and stepping change only how you watch the run, never the numbers it produces.
Can I make it show tails instead of heads? The running line and the streak counter are fixed on heads. Tails is the mirror image — P(Tails) is 100% minus the value shown, and both bars are always visible in the distribution chart.
It is the theorem that as you repeat an independent random trial more and more times, the observed proportion converges to the true probability. For a fair coin, the fraction of heads approaches 0.5. This simulator makes that convergence visible as you increase the number of flips.
The law of large numbers governs the proportion, not the raw counts. The absolute difference between heads and tails can keep growing even while the fraction of heads gets closer to 50%. Watching both readouts at once is the clearest way to see why those two facts do not contradict each other.
It depends on how close. The typical deviation from 50% shrinks with one over the square root of the number of flips, so 100 flips often land within a few percent and 10,000 flips usually sit within a fraction of a percent. Run different sizes in the simulator to see the scaling for yourself.
Yes — it was designed for it. Run live convergence demos, export the converging chart as a PNG, or copy the embed code to place the interactive simulator directly on a lesson page or slide. The presets (10 to 100,000 flips) and speed control let you pace the demonstration for a class.
In spirit, yes. A Monte Carlo method estimates a quantity by repeated random sampling, which is exactly what this does — it estimates P(heads) by sampling many flips. The coin is the simplest possible Monte Carlo experiment, which makes it ideal for first learning how the technique converges on an answer.