Random Number Generator

The real problem with Math.random is not the one you have read about

Almost every random number generator on the web is built on Math.random, and almost every page explaining why that is a problem says the same thing: that it is biased, that some numbers come up more often than others. That claim is, for practical purposes, false — and repeating it gets in the way of the real objection.

The usual implementation is Math.floor(Math.random() * n). It does distribute unevenly, because the generator produces one of roughly 2⁵³ values and those do not divide evenly into a range. Counted exactly for a range of 100, the excess is about one part in 10¹⁴, and it grows only in proportion to the size of the range. At that size you could draw a number every nanosecond since the beginning of the universe and still not have the evidence to detect it. Nobody has ever lost anything to it.

What Math.random actually is, is predictable. It is a deterministic generator with a small internal state. Given a short run of its output, that state can be recovered — and from the state, every value it will produce next, and every value it already produced. It passes the statistical tests you would think to run, and it fails the only one that matters when the number decides something in the open: nobody watching should be able to work out what comes next. This page draws from crypto.getRandomValues instead, and never falls back — if that source were missing, it says so rather than quietly substituting the weaker one, because the two produce output you cannot tell apart.

Where modulo bias is real, and why this page has to handle it

Dismissing the bias claim above does not make the problem disappear; it moves it. A cryptographic source does not hand you a number in your range, it hands you bytes. Turn one byte into a number from 1 to 100 with a remainder and the skew is not one part in 10¹⁴, it is 50%: of the 256 possible bytes, the first 56 values in the range get three chances each and the remaining 44 get two.

So this page does the arithmetic properly. It works out how many bits your range actually needs, reads enough whole bytes to cover them, masks the value down to exactly that many bits — which is exact rather than approximate, because a power of two divides a power of two — and discards anything still above the range rather than folding it back in. Every number in the range ends up with precisely equal probability, not approximately equal. The same technique is what makes the Password Generator honest, and for the same reason.

Drawing without repeats is where generators actually break

Asking for six different numbers is a different operation from asking for six numbers, and two wrong ways of doing it are everywhere.

The first is to draw and discard duplicates until enough unique values have appeared. It is correct, and its cost climbs steeply as the count approaches the size of the range: asking for ten different numbers between one and ten means the last one has a one-in-ten chance of being useful on each attempt, and the last of a million numbers from a million has a one-in-a-million chance — a million attempts, on average, for one number.

The second is to shuffle by sorting — array.sort(() => Math.random() - 0.5), the single most copied snippet in this corner of the web. It is not a shuffle. It hands the sort a comparator that gives a different answer each time it is asked the same question, and every sorting algorithm is built on the assumption that this never happens; the result reflects the algorithm's internals, not chance. Measured over 200,000 shuffles of six items in Chrome's engine: the first item finished first 56,915 times where 33,333 was expected — 71% more often than it should — and finished third only about 20,000 times. Every item had a position it favored. Anyone drawing a running order that way has been handing out an advantage.

This page uses a partial Fisher–Yates shuffle, which picks each value in a single step and never revisits one, over a sparse map rather than a real array. That last detail is what lets you draw six numbers from one to a billion: the range is never built, only the handful of positions actually touched.

What this page cannot do

It cannot prove to anyone that a draw was fair. Nothing that produces a result and then describes it can — once the numbers exist, there is nothing to distinguish a single honest draw from the twentieth attempt at one, and any page claiming otherwise is selling you a badge.

If a result has to be accepted by people who were not watching, the order of operations has to change rather than the tool: commit publicly to something before the draw — a seed you publish, or a future public number like a national lottery result — so that afterwards anyone can check the outcome followed from it. That is a genuinely different procedure, and saying so is more useful than a reassurance.

Nothing is sent

This is a static page with no server behind it, so there is structurally nowhere for a drawn number to go. The first draw happens inside your browser a moment after the page finishes loading, never while the page is being built, because a number computed at build time would be baked into the page and handed to every visitor identically. Load the page twice and the draws differ, and neither ever appears in the page's own HTML.