True Random Number APIs vs. a Browser’s Built-In Generator: What’s the Difference?
A true random number API such as random.org generates values from measured atmospheric radio noise, a physical unpredictable process; a browser’s crypto.getRandomValues() produces cryptographically strong output from an algorithm periodically reseeded with hardware-derived entropy rather than a live external signal. Both can deliver a fair, unpredictable result — they differ in where the unpredictability originates and whether a network request is required.
A worked example with numbers
RANDOM.ORG describes generating randomness from atmospheric noise picked up by an array of radios, producing on the order of 12,000 bits per second of raw material for its generators, then distributing that material to callers through an HTTP or JSON-RPC API that requires a registered key and enforces a daily quota on how many bits an account may request. A browser call to crypto.getRandomValues(), by contrast, returns instantly, requires no network round trip, no API key, and no quota, because it draws from the operating system’s own entropy pool rather than a shared external service. That entropy pool is itself periodically refreshed from hardware-level sources such as timing jitter and, on many systems, a dedicated hardware random-number generator, so “pseudorandom” in this context means algorithmically stretched from real local entropy, not detached from any physical source at all.
How to set the rule before the result
For a page that generates results entirely client-side — the model this site’s tools use — crypto.getRandomValues() is the appropriate choice: it needs no account, works offline once the page is loaded, and sends no request to a third party. Reach for a network-based true-random API only when a project specifically needs a documented, timestamped, third-party-attested draw — for example, an academic study or a competition that wants to point to an external, non-repeatable physical source rather than code the organiser controls. Between those two extremes, some projects choose a middle path: generate the result locally for speed and privacy, then periodically spot-check the local generator’s long-run statistics against a trusted external reference, which captures most of the benefit of an audit without paying the latency and quota cost on every single call.
Common mistakes that change the odds or the process
A common mistake is assuming “true random” automatically means “more fair” for an ordinary decision. For selecting one of two, six, or a dozen equally likely outcomes, a well-implemented cryptographic pseudorandom source is statistically indistinguishable from atmospheric noise in practice; the meaningful difference is about where the unpredictability comes from and whether it can be audited afterward, not about which produces a “more equal” split. A second mistake is calling a network API from a page that also needs to work offline or that promises not to send data to a third party — those requirements conflict with any external service call, regardless of how the service generates its numbers. A third mistake is assuming a paid quota or an API key requirement is itself evidence of higher quality; a usage limit exists to manage the service’s operating costs and prevent abuse, and says nothing about whether its output is more or less suitable for a given task than a free, unlimited local alternative.
Where this method stops being appropriate
A network-based true-random API introduces latency, a dependency on that service staying online, a per-account usage quota, and a third party that sees each request; none of those trade-offs are appropriate for a lightweight, privacy-preserving browser tool meant to work instantly and offline. Conversely, a browser’s local generator provides no independent, external timestamp or third-party attestation, so it is not a substitute for a documented audit trail when one is genuinely required. Neither source, on its own, resolves a dispute about the surrounding process — who was eligible, what the rule was, and whether the result was applied as announced — since both a physical radio array and a browser algorithm only answer the narrower question of how one number was produced.
How the random source fits into the rule
RANDOM.ORG’s introduction to randomness describes its atmospheric-noise radio array and approximate bit rate; MDN’s Crypto.getRandomValues reference documents the browser’s local cryptographic alternative. Both sources describe how their respective randomness is produced rather than certifying any particular downstream use of it, so neither reference by itself settles whether a specific website applies the resulting values correctly.
Why this site’s tools do not call an external random API
Generating every result locally in the browser means a page does not need to send a network request, share a visitor’s activity with a third-party service, wait for a round trip, or depend on that service’s uptime and quota limits. For a coin flip, dice roll, or list pick — where the practical requirement is an unpredictable, uniform result, not a documented external attestation — the browser’s own cryptographic API meets that requirement without any of those costs.
There is also a fairness-adjacent reason: a page that needs a network call to function is unusable the moment that network is unavailable, turning a simple decision tool into a service outage. A locally generated result keeps working on a train, on a flight, or during a genuine internet interruption, which matters more for a casual decision tool than any marginal difference between two already-fair random sources.
What an audit trail from a network RNG actually proves
A timestamped, third-party-generated value can show that an organisation controlled by neither party produced a number at a specific moment, which is useful when participants do not trust each other’s software. It does not, by itself, prove the number was applied correctly afterward, that no other step in the process was tampered with, or that the requesting party did not simply discard an inconvenient draw and request another — the same procedural honesty required of any random method still has to be supplied by the people running the process, not by the API.
An audit trail is therefore most valuable as one input to a larger documented procedure — alongside a frozen participant list, a stated rule, and a published result — rather than as a standalone guarantee. A network RNG without those surrounding practices is no more trustworthy than a local one used the same careless way; the API upgrades the source of the number, not the discipline of the people using it.
A useful comparison is a notarised paper document versus an unwitnessed handwritten note: the notarisation adds a verifiable record of when and by whom the document was produced, but it does not by itself make the document’s content true or its later use honest. A network true-random API plays roughly the same role for a number as a notary plays for a signature — valuable for a specific kind of dispute, unnecessary for most everyday decisions.
Why the numbers alone cannot tell you which source produced them
A well-implemented cryptographic pseudorandom generator and a genuine physical noise source are built to satisfy the same statistical standard — the kind of test battery documented in NIST SP 800-22 — and a sequence that passes that battery gives no indication of which kind of process produced it. Statistical randomness is a property of the output; the true-versus-pseudo distinction is a property of the mechanism that generated it. Reading a printed list of numbers cannot recover that mechanism, which is why the two are usually compared on latency, cost, and dependency instead of on any measurable difference in fairness.
A second case: how much randomness different tasks actually need
Not every random result costs the same in raw entropy. A single fair coin flip needs exactly 1 bit. A fair d6 roll needs a theoretical minimum of log₂(6) ≈ 2.58 bits, though a practical byte-based implementation using rejection sampling — discarding byte values 252 through 255 so 0 through 251 map evenly onto six faces — uses an average of about 1.016 bytes, roughly 8.13 bits, per roll because of the small amount of wasted, rejected byte space. A complete, uniformly shuffled 52-card deck needs about log₂(52!) ≈ 225.58 bits, since there are 52! possible orderings and every one must stay equally reachable. Both random.org’s atmospheric-noise generator and a browser’s crypto API can supply any of these amounts; the difference lies only in how the bits are packaged and delivered, not in how much randomness either source can fundamentally provide.
The “0.02 percentage points proves it” mistake
Suppose two testers each run 10,000 flips, one against a network true-random API and one against a browser’s local generator, and report 50.02% heads from one source and 49.98% from the other. Neither number means anything on its own: at n = 10,000, the standard error of a fair coin’s observed proportion is √(0.25 ÷ 10,000) = 0.5 percentage points, roughly twelve times larger than the 0.04-percentage-point gap between the two reported results. Treating that gap as evidence one source is “more fair” than the other mistakes ordinary sampling noise for a real difference; distinguishing two sources this close would need a sample far larger than 10,000 flips from each.
How you would actually check either source yourself
The same 95%-confidence, 1-percentage-point sample size used elsewhere on this site — about 9,604 trials — applies to testing either source for bias. The practical difference shows up in how that sample gets collected: 9,604 local calls to crypto.getRandomValues() complete in a browser tab in well under a second, with no network cost at all, while 9,604 separate calls to a quota-limited network API would take meaningfully longer and consume a real fraction of a typical daily usage allowance. That gap in practical testing cost is a genuine, measurable difference between the two approaches — it just is not a difference in fairness.
What output testing cannot cover: who controls the source
Neither a statistical pass nor a bit-cost comparison says anything about the trust model behind either source. A browser’s local generator lives on the visitor’s own device, so its integrity depends on that device not being compromised by malware capable of manipulating its state — a risk a website cannot see or rule out. A network true-random API instead depends on a separate organisation’s infrastructure staying honest and uncompromised, a different kind of risk entirely. Choosing between them is partly a decision about which party you are willing to trust, a question no amount of statistical testing of the resulting numbers can settle.