The 30-second summary
Random.org generates random numbers from atmospheric noise — a true hardware entropy source operated by a trusted third party since 1998. Provable.io generates random numbers from a seeded HMAC-SHA256 stream and publishes a hash of the server seed before the result, so anyone can independently re-derive and verify the outcome after the fact.
The difference is the trust model. Random.org asks you to trust the operator; Provable.io asks you to trust the math. Both are legitimate answers — they're just answers to different questions.
Feature matrix
| Capability | Provable.io | Random.org |
|---|---|---|
| Entropy source | HMAC-SHA256 over a committed server seed + client seed | Atmospheric noise (radio) |
| Public verifiability of a past draw | Yes — publish serverHash, then reveal seed; anyone can re-derive | Signed API responses (paid tier) — verifier must trust Random.org's keypair |
| Free tier | Free, unauthenticated and authenticated | Free quota of bits per day per IP; paid for higher volume |
| Open-source generator | Yes — provable-core on GitHub | No — proprietary backend |
| Reproducible from a seed | Yes (that's the whole point) | No — by design, each call is fresh entropy |
| Commit-reveal flow | First-class: /api/commit + /api/reveal | Not applicable |
| Game-style primitives | floats, ints, dice (3d6), shuffle, weighted pick, bytes, distributions | integers, sequences, strings, gaussians |
| Webhooks | Yes (HMAC-signed) | No |
| Streaming (SSE) | Yes, with Last-Event-ID resume | No |
| Self-hostable | Yes — the core library runs offline | No |
When Random.org is the right answer
Random.org wins anywhere the requirement is literally "non-deterministic, hardware-sourced randomness drawn at the moment of the call." That includes:
- Physics simulations and statistical sampling where seedability is an anti-feature — you want every run to differ.
- One-off prize draws where the draw is conducted live, the operator is trusted by the participants, and reproducibility isn't a requirement.
- Cryptographic key material in an environment without a CSPRNG (rare today — most platforms expose one).
When Provable.io is the right answer
Provable.io wins anywhere a third party — a user, an auditor, a regulator, your future self — needs to check that the result you reported is the result the algorithm actually produced. That includes:
- Online raffles and giveaways where the audience can't be in the room. See the raffle picker API page.
- Card and dice games where players want to confirm the shuffle wasn't rigged. See the card shuffler API and dice roller API.
- A/B test bucket assignments that have to be re-derivable months later for a compliance review. See A/B test bucketing.
- NFT trait generation at mint time, where holders demand proof the rare drops weren't pre-allocated.
- Loot tables and gacha pulls where players want to audit the drop rate distribution against the published odds.
Try a verifiable draw right now
This is the equivalent of Random.org's "give me five integers between 1 and 100" — except the response includes a serverHash you can paste into /verify to confirm the result wasn't fabricated.
curl "https://api.provable.io/api/ints?clientSeed=compare-random-org&count=5&min=1&max=100"How verification actually works
Provable.io commits a hash of the next server seed before you call it. When the call happens, the response includes the seed in plaintext and the corresponding hash. You (or anyone) can:
- Confirm
sha256(serverSeed) === serverHash. - Replay
HMAC_SHA256(serverSeed, clientSeed + ":" + cursor + ":" + nonce)to derive the bytes. - Apply the same uniform-integer mapping to confirm the published outcome.
The whole pipeline is in the open-source provable-core npm package — you don't have to trust our server to run it. See How provably fair works for the full walkthrough.
FAQ
Is Provable.io's HMAC stream as "random" as atmospheric noise?
For practical purposes, yes. HMAC-SHA256 with a strong server seed is computationally indistinguishable from uniform randomness — it's the same primitive that backs TLS session keys. The tradeoff is the seed: someone who knows it can re-derive the stream, which is exactly what makes verification possible.
Can I use both?
Sure. A common pattern is to use Random.org to mint your client seed (so the seed is provably not influenced by you), then call Provable.io with that seed. The combination gives you fresh entropy plus public verifiability.
What about latency and rate limits?
Provable.io is free and unauthenticated up to a generous rate limit, with per-account daily quotas above that. Random.org meters by random bits per day per IP and charges for higher volumes. For most app workloads, both are comfortably fast (tens of milliseconds).