Is a Browser Random Number Generator Truly Random?
A pseudorandom number generator, or PRNG, is an algorithm that produces a sequence from an internal state rather than measuring a new physical event for every output.
A worked example with numbers
A page needs one integer from 1 through 6. It can obtain a 32-bit unsigned value, reject values above the largest multiple of 6 below 2^32, then use the remainder plus 1. Each die face receives the same count of accepted source values. The result is not a physical die tumble, yet it has a clear equal-probability model. The problem changes if the output must protect a password, secret key, or security token: then predicting future values can be harmful even if the six displayed faces look balanced.
How to set the rule before the result
JavaScript exposes two commonly discussed sources. `Math.random()` returns a pseudo-random floating-point value at least 0 and below 1. It is convenient for an animation frame or a low-stakes simulation, but MDN explicitly says it is not cryptographically secure. `crypto.getRandomValues()` fills an integer typed array with cryptographically strong values. MDN also notes that the browser may use a PRNG seeded with enough entropy rather than a literal physical random-number device; “cryptographically strong” is a security property, not a claim that every output comes from a radioactive detector. See MDN’s Math.random reference and MDN’s Crypto.getRandomValues reference.
Common mistakes that change the odds or the process
Avoid treating one observed sequence as a test of the generator. Six heads in a row has probability (1/2)^6 = 1/64, about 1.56%, under independent fair coin trials; rare sequences are expected when enough people generate results. Avoid converting a floating result with rounding when a range needs equal endpoints: `Math.round(random * 5)` gives the endpoints only half the width of middle intervals. Avoid modulo reduction without rejection for an arbitrary source range, because unequal remainder counts can introduce small bias.
Where this method stops being appropriate
For games, classroom demonstrations, list order, and casual ties, a browser result can be practical when the list and rule are visible. It is not proof of a legal drawing, a secure password vault, a protected gambling system, or an audit trail. Device compromise, malicious page code, a changed input list, and an unrecorded rerun lie outside the distribution of the numeric source. The right question is not “is it truly random?” in isolation; it is “is this source and procedure adequate for the consequence?”
How the random source fits into the rule
The die roller, random integer generator, and list shuffler use a defined finite population rather than claiming to discover truth. NIST’s statistical-test publication, NIST SP 800-22, treats tests as evidence under assumptions; a passing test suite does not certify every future output or prove an entire application is honest.
What “random” can and cannot promise in a browser
Physical randomness and usable browser randomness answer different questions. A physical device may sample noise from a process outside a computer; a browser normally asks an operating-system service for entropy and expands it through a generator. For a die face, the relevant property is that the six final classes are equally reachable and that a user cannot use the page history to choose a preferred face. For a secret, the stronger property is resistance to prediction even when an attacker sees earlier outputs. Calling both things simply “random” hides that difference.
Test results cannot fill the gap. A million outputs may look balanced while an attacker who knows a weak seed predicts the next one. Conversely, a good source may produce five identical values in a short run. Inspect the API and the range mapping, then select a method suited to the risk. A local dice result is a convenience calculation; a credential needs a security design that includes storage, transport, recovery, and device protection as well as the random source.