Coin Flip vs. Dice Roll: Which One Actually Carries More Randomness?

A single fair coin flip carries exactly 1 bit of randomness, because log2(2) = 1; a fair six-sided die carries about 2.585 bits, because log2(6) ≈ 2.585. Randomness in this sense is measured in bits by taking log2 of the number of equally likely outcomes a single draw can produce — the same yardstick a computer uses to size a random draw internally, not a loose sense of how unpredictable something feels.

A worked example with numbers

Working the same formula across common sources shows the pattern clearly: a d4 carries log2(4) = 2 bits exactly, a d6 carries about 2.585 bits, a d8 carries log2(8) = 3 bits exactly, a d10 carries about 3.322 bits, a d12 about 3.585 bits, a d20 about 4.322 bits, and a d100 about 6.644 bits. Three independent coin flips together carry exactly 3 bits — precisely log2(8), the same figure as one d8 roll — because independent bits add: flipping three coins and reading Heads as 1 and Tails as 0 produces one of exactly 8 equally likely three-digit binary strings, from 000 through 111, an exact stand-in for a single d8 roll relabelled 0 through 7. A d6, by contrast, carries less than 3 bits (2.585 rather than 3), meaning three coin flips actually carry slightly more raw information than one six-sided die roll: a d6’s six outcomes cannot be produced from exactly three fair flips without either discarding some flip combinations or grouping the die’s faces unevenly across the flip outcomes.

How to set the rule before the result

Verify this directly with a short calculation: enumerate a source’s equally likely outcomes, count them, and take log2 of that count — Python’s math.log2() confirms every figure above to four decimal places without needing a lookup table. To feel the difference physically rather than just numerically, generate three flips with the multiple-coin flip tool and compare the spread of eight possible sequences against eight rolls from the d8 roller; both draw from an equally sized, equally likely outcome set, even though one comes from three separate binary events and the other from a single eight-sided draw. A useful sanity check for any custom generator: if it is meant to replace k coin flips, it should offer exactly 2^k equally likely outputs, no more and no fewer, or it is not truly standing in for k independent bits.

Common mistakes that change the odds or the process

A common mistake is assuming “more sides always means more randomness” in an unbounded sense; bits grow only logarithmically with outcome count, so doubling a die’s number of sides adds exactly one bit, not double the randomness — going from a d10 (3.322 bits) to a d20 (4.322 bits) adds one bit for double the faces, while going from a d20 to a d40 would add only one more bit again, not two. A second mistake is assuming any number of coin flips can stand in cleanly for any die without checking the numbers first; 3 flips maps exactly onto a d8 because 2³ = 8 lands on a whole number, but attempting to map flips directly onto a d6 or d10 hits the same modulo-bias problem covered in this site’s piece on picking one NFL, NBA, or MLB team fairly, since 2^k never divides evenly by 6 or 10 for any whole k. A third mistake is confusing this counting concept, “how many bits label the outcome space,” with security or unpredictability — a badly designed linear congruential generator can output values from a source with plenty of bits per draw while still being fully predictable once its formula leaks, the separate concern covered in this site’s comparison of legacy algorithms against modern cryptographic generators.

Where this method stops being appropriate

This bit-counting only applies to sources where every outcome is genuinely equally likely; a biased coin or a physically unbalanced die carries strictly less than its ideal log2(N) bits, since Shannon’s entropy formula gives a lower figure whenever outcome probabilities are unequal rather than uniform — a distinction from the min-entropy assessment a certified hardware source must document, covered elsewhere on this site. It also says nothing about whether a source is cryptographically unpredictable; a fully deterministic, publicly known formula can still technically offer log2(N) bits of labeled outcome space per draw while being completely guessable in advance, which is why bit-counting answers “how large is the labeled outcome space” and nothing about whether an adversary could predict which label comes next.

How the random source fits into the rule

MDN’s Math.random reference documents the uniform interval a browser’s core random source draws from, the same equally-likely-outcomes assumption this bit-counting relies on; NIST SP 800-90B documents min-entropy as the standard, more conservative measure used once outcomes are not assumed to be perfectly equal, the case this article’s simple log2(N) figures do not cover.

Bits of randomness for common sources

Bits climb slowly on purpose: this is exactly the same log2 scale used to size how many coin flips or bytes a computer needs to represent a given range without waste, the same underlying arithmetic behind the range-conversion and rejection-sampling techniques used elsewhere on this site.

A second case: why summing two dice does not simply double their bit count in a useful way

Two independent d6 rolls together carry log2(36) ≈ 5.170 bits, exactly 2 × 2.585 bits, confirming that independent draws’ bit counts add cleanly. But reading only the two dice’s sum — 2 through 12 — throws information away: many different (die 1, die 2) pairs map to the same sum, so the sum alone carries noticeably fewer than 5.170 usable bits, which is the deeper reason the two-dice sum distribution is not flat. The full 5.170 bits describe the pair of individual die results; the sum is a lossy summary of that pair, not a separate, smaller random draw in its own right.

A practical case: replacing a d100 with coin flips

Since log2(100) ≈ 6.644 bits and 6 coin flips supply only 2⁶ = 64 combinations — too few — a d100 needs at least 7 flips, which supply 2⁷ = 128 combinations. Mapping those 128 combinations onto 100 valid outputs and discarding the remaining 28 (values 100 through 127) via rejection sampling gives an exact, unbiased d100 substitute built entirely from coin flips, at the cost of discarding roughly 21.9% of raw 7-flip sequences and drawing again. This is the same rejection-sampling principle, applied to an information-theoretic starting point instead of a byte, used throughout this site’s guides on generating a random integer without modulo bias.

How many bits a fair choice among people actually needs

Group sizes that happen to be an exact power of two need no rejection step at all, since 2^k flips map onto exactly 2^k people with nothing left over — a genuinely useful shortcut worth checking before reaching for a more general integer-range tool, since a plain sequence of coin flips is often the simplest available fair source for a group whose size happens to land on a clean power of two. A group size that does not land on a clean power of two, such as 100, still gets an exact and unbiased result from the same coin-flip source once rejection sampling is added, at the modest cost of occasionally discarding and repeating a 7-flip sequence.

Related DiceDecide tools

• Flip several coins in one batch
• Roll a single eight-sided die
• Read why two summed dice are not equally likely
• Draw a bounded random integer directly