What a Random-Number API’s Daily Quota Actually Limits (and When a Browser Generator Has No Such Limit)
RANDOM.ORG’s HTTP API allocates each client a starting quota of 1,000,000 bits, adds a free top-up of 200,000 bits per day once the balance falls below the 1,000,000-bit ceiling, and returns a 503 error response on further requests once the balance goes negative — notably, the server still fully completes whichever single request first pushes the balance negative, rather than rejecting it outright, and only starts erroring on the requests after that. A browser’s built-in crypto.getRandomValues() call has no equivalent limit at all, because it never leaves the visitor’s own device to reach a shared server in the first place.
A worked example with numbers
What a request actually costs against that quota depends on the size of the range requested, not on the number of requests made. RANDOM.ORG’s own accounting charges based on the bit-size of the requested range, meaning a single integer drawn from 1–100 costs log2(100) ≈ 6.644 bits, while a single coin flip (a 1-or-2 draw) costs only log2(2) = 1 bit — a 6.6-times difference for what might look like “one random number” in either case. Spread across the full 1,000,000-bit starting quota, that difference is substantial: it supports roughly 1,000,000 individual coin flips, roughly 386,853 individual d6 rolls (at log2(6) ≈ 2.585 bits each), roughly 150,515 individual 1–100 integers, and only about 75,257 individual 4-digit PINs (at log2(10,000) ≈ 13.288 bits each, since a 4-digit PIN has 10,000 possible values) before the starting balance is exhausted.
How to set the rule before the result
Anyone integrating a network true-random API into a real tool should check the service’s own quota-status endpoint before and after a batch of requests, and follow its documented backoff guidance — RANDOM.ORG’s own recommendation is to wait at least ten minutes once a client’s balance goes negative before retrying, rather than immediately hammering the endpoint with repeated requests. A browser generator needs none of this quota-tracking or backoff code at all, which is precisely why a casual, everyday tool making frequent small draws — this site’s own coin, dice, and number generators among them — uses the local browser source rather than an external network API: there is no meaningful randomness-quality gap to justify accepting a quota, a network dependency, and an offline failure mode for draws where nothing of real consequence hinges on the source being externally attested.
Common mistakes that change the odds or the process
A common mistake is assuming a service advertised as free has no real usage ceiling at all; RANDOM.ORG’s quota is a specific, documented, numeric limit, and exceeding it does not silently degrade output quality — it starts returning outright errors instead. A second mistake is assuming quota is tracked per individual user; it is tracked per IP address, so multiple people, devices, or services sitting behind the same network address share a single pool without necessarily realizing it, an operationally important detail for anyone deploying a shared tool behind one corporate or home network. A third mistake is assuming a request that would push the balance negative gets rejected before it runs; the documented behavior is the opposite — that one final request completes in full, taking the balance negative, and only the requests after it start failing, a subtlety worth building into any retry logic rather than assuming a hard pre-check cutoff exists.
Where this method stops being appropriate
These specific figures — the 1,000,000-bit starting quota, the 200,000-bit daily top-up, and the 503 error on a negative balance — describe RANDOM.ORG’s free Basic API as currently documented; a different true-random service, or RANDOM.ORG’s own separate paid commercial tier, uses different limits not covered by any of the numbers above, so the live documentation of whichever specific service is actually being integrated should always be checked directly rather than assuming these figures transfer. This article also covers operational availability only — whether a usable answer can be obtained right now, within quota — a separate question from the statistical and philosophical true-random-versus-algorithmic comparison covered in this site’s guide to true-random APIs versus a browser’s built-in generator.
How the random source fits into the rule
RANDOM.ORG’s HTTP API documentation documents the starting quota, daily top-up, and negative-balance behavior described above; MDN’s Crypto.getRandomValues reference documents the browser-local alternative that carries no equivalent quota because it never reaches an external server.
How far the starting 1,000,000-bit quota reaches, by request type
| Request type | Bits per draw | Draws from a 1,000,000-bit starting quota |
|---|---|---|
| Coin flip | 1.000 | ~1,000,000 |
| d6 roll | 2.585 | ~386,853 |
| 1–100 integer | 6.644 | ~150,515 |
| 4-digit PIN | 13.288 | ~75,257 |
The same 1,000,000-bit starting balance reaches over 13 times further for plain coin flips than for 4-digit PINs, simply because each PIN draw encodes far more information per request — the number of requests made is a poor proxy for quota usage unless the size of each individual draw is also accounted for.
A second case: planning a daily usage budget correctly
Suppose a tool needs 50,000 draws per day of a 1–100 integer, each costing about 6.644 bits, for a daily total of roughly 332,193 bits. Against a starting balance of 1,000,000 bits, that pace would exhaust the initial quota in about 3 days — but the ongoing 200,000-bit daily top-up falls short of the 332,193-bit daily need by about 132,193 bits every single day once the starting cushion runs out, meaning the balance would go negative and stay negative under sustained use at that rate. The starting 1,000,000-bit quota functions as a one-time burst allowance, not a renewable daily budget; any tool with steady, ongoing usage needs to stay under the 200,000-bit daily top-up rate specifically, not just under the larger starting figure, to remain sustainable long-term.
RANDOM.ORG’s API vs. a browser generator, by practical dimension
| RANDOM.ORG HTTP API | Browser crypto.getRandomValues() | |
|---|---|---|
| Network required | Yes | No |
| Usage quota | Yes, numeric and documented | None |
| Works offline | No | Yes |
| Third-party attestation | Yes, from an independent service | No, generated entirely on-device |
Neither column is the objectively “better” choice — a dispute-resolution or audit-sensitive use case benefits from the third-party attestation a network API provides, while a casual, high-frequency, or offline-capable tool benefits from a browser generator’s complete lack of quota and network dependency.
A shared-IP quota gotcha worth planning for
Because RANDOM.ORG tracks quota per IP address rather than per individual visitor, several separate browser tabs, several different visitors on the same office or home network, or several instances of the same tool running behind one shared network gateway all draw against the identical quota pool without any of them necessarily being aware the others exist. A tool built around this API that assumes each visitor effectively gets their own private 1,000,000-bit allowance will be surprised the first time a shared-network deployment depletes that allowance far faster than a single-visitor testing session ever suggested it would. Tracking and logging quota usage server-side, rather than assuming client-side isolation, is the practical fix for any deployment where more than one visitor might plausibly share a network address. A browser-local generator sidesteps this entire class of problem, since each visitor’s device generates its own values independently with nothing to share, track, or accidentally exhaust on another visitor’s behalf.