Random.org vs Built-in Random: Which Raffle Draw Method Is Actually Fair?

"Was the draw fair?"

That question comes up after every raffle. Sometimes from a disappointed participant. Sometimes from a charity board reviewing compliance. Sometimes from a regulator in Ontario who needs to see documentation.

The answer depends entirely on how the winning ticket was selected. Not whether the plugin says "random" in its settings. Not whether the draw looked random. Whether the underlying method is actually, verifiably, mathematically random.

We build Raffle for WooCommerce, so we spent serious time on this. Our plugin offers three selection methods: WordPress standard random, PHP's cryptographically secure random_int(), and Random.org's atmospheric noise generator. Each one works differently, has different strengths, and is appropriate for different situations.

This guide covers what each method actually does under the hood, where the randomness comes from, and which one you should use for your specific raffle.

What "random" means (and why most software gets it wrong)

True randomness requires unpredictability. No pattern, no seed, no algorithm that could reproduce the same sequence if you knew the starting conditions.

Most software doesn't generate true random numbers. It generates pseudorandom numbers, sequences that look random but are produced by deterministic algorithms. Given the same starting seed, the algorithm produces the same sequence every time. That's not a bug. It's how pseudorandom number generators (PRNGs) work by design.

For most applications, pseudorandom is fine. Shuffling a playlist, randomizing product display order, generating test data. Nobody cares if the shuffle was "truly" random.

Raffles are different. When money is involved, when prizes have real value, when charity compliance requires documentation, "looks random" isn't enough. You need either cryptographic guarantees that the output can't be predicted, or physical randomness that no algorithm produced at all.

The three methods, explained

1. Standard Random (WordPress wp_rand())

This is the default. When WordPress needs a random number, it uses a function called wp_rand(), which relies on a well-known algorithm called Mersenne Twister, designed in 1997. Most WordPress plugins that claim to pick "random" winners use this method.

How it works: The algorithm starts with a starting number (called a "seed") and runs it through a series of mathematical transformations to produce a sequence of numbers. The sequence is enormously long before it repeats.

The problem: Mersenne Twister is deterministic. If you know the starting seed, you know every number the algorithm will produce. And there are only about 4.3 billion possible seeds, which sounds like a lot but isn't for a modern computer.

This isn't theoretical. A tool called php_mt_seed can recover the seed from observed outputs. On a modern quad-core CPU, it searches the full 32-bit seed space in under a minute. Security researchers at White Knight Labs demonstrated in 2024 that with just two known mt_rand() values, the entire sequence can be reconstructed, both past and future outputs.

For a raffle: if someone can observe any output from the same mt_rand() state (which is shared across a PHP request), they could theoretically predict the winner. In practice, exploiting this in a WooCommerce raffle requires specific conditions, but the mathematical vulnerability exists.

Where it's fine: Small, informal draws where nobody is going to question the method. Office pools, fun giveaways, low-stakes promotions. The randomness looks good to any observer and the distribution is uniform.

Where it falls short: Any raffle where fairness needs to be demonstrated, documented, or audited. Charity raffles. Raffles with valuable prizes. Any situation where "trust me, it was random" isn't sufficient.

2. Cryptographically Secure (random_int())

This is the secure option built into modern PHP (version 7.0 and later). Instead of a predictable algorithm, it uses your server's own hardware activity as a source of randomness. The technical name is a cryptographically secure pseudorandom number generator (CSPRNG), but what matters is this: nobody can predict or reverse-engineer the output.

How it works: random_int() pulls entropy from your operating system's randomness pool:

These sources collect unpredictable physical events from the hardware and mix them into a pool of entropy. The numbers that come out can't be predicted even if you know everything about the software.

The key difference from mt_rand(): There is no seed to recover. The entropy comes from physical events that are genuinely unpredictable. No tool can brute-force the output because there's no 32-bit seed to search.

Performance: random_int() is slower than mt_rand(). Benchmarks on PHP 7.4 show random_int() taking roughly 29x longer per call (9.2 seconds vs 0.32 seconds for 10 million iterations). For a raffle draw that selects one winner from a few hundred tickets, this difference is imperceptible. You're talking about microseconds, not seconds.

Standards compliance: random_int() uses entropy sources that align with NIST SP 800-90A recommendations for random number generation. The specific CSPRNG mechanisms (Hash_DRBG, HMAC_DRBG, CTR_DRBG) defined in that standard are what operating systems implement internally.

Where it's strong: Any raffle where you need genuine unpredictability. The output can't be predicted, even by someone with access to the server. For most WooCommerce raffles, this provides more than enough security.

Where it falls short: You can prove the numbers were generated securely (based on the code), but you can't independently verify a specific draw result after the fact. There's no external audit trail. If someone asks "prove this particular draw on March 15 was fair," you can show your code uses random_int(), but you can't produce a certificate for that specific draw.

3. Random.org (True Random from Atmospheric Noise)

Random.org generates true random numbers from atmospheric noise, specifically radio frequency noise caused by natural atmospheric processes including lightning discharges around the planet. The service has been operational since 1998 and is run by Randomness and Integrity Services Ltd., founded by Dr. Mads Haahr at Trinity College Dublin.

How it works: Radio receivers capture atmospheric noise, which is inherently unpredictable. This raw noise is processed into uniform random numbers. The data is never padded with hashing functions, preserving maximum entropy. All output undergoes real-time statistical testing before delivery.

Independent certification: Random.org is independently certified by Gaming Labs International (GLI), the same organization that certifies randomness for casinos and state lotteries. GLI's standard GLI-31 specifically covers electronic raffle systems. This certification is renewed on a regular basis.

The Signed API: This is what makes Random.org fundamentally different for raffle compliance. The Signed API returns random values with a digital signature that includes:

• The random values generated
• A unique serial number for the request
• A SHA-512 hash of the data
• Timestamp of generation
• The method used to generate the values

Anyone can verify the signature against Random.org's public key. This proves that the specific numbers used in your draw were genuinely generated by Random.org at that specific time, and haven't been altered since.

What this means for raffles: If a charity board, a regulator, or a skeptical participant asks you to prove a draw was fair, you can hand them the signed response. They can independently verify it at random.org/signatures. No trust in your organization required. No trust in the plugin developer required. The proof is cryptographic and third-party verifiable.

Pricing: Random.org offers a free tier with 250,000 bits/day (enough for hundreds of raffle draws). Paid plans start at $5/month for higher volumes. For most WooCommerce raffles, the free tier is more than sufficient.

Side-by-side comparison

In plain language: Standard Random is like rolling dice made by a computer (predictable if you know the formula). Cryptographically Secure is like rolling dice made from electronic noise inside your server (unpredictable, but you can't prove it to others). Random.org is like rolling dice made from actual lightning in the atmosphere (unpredictable, and you get a signed receipt proving it).

Which method should you use?

The right choice depends on what's at stake and who you need to satisfy.

Use Standard Random when:

• It's an informal office draw or fun promotion
• The prize value is low (under $100)
• Nobody is going to question the method
• Speed matters more than provability

Use Cryptographically Secure when:

• The prize has meaningful value
• You want genuine unpredictability
• You need to demonstrate good practice if asked
• The draw is internal and you control the narrative

Use Random.org when:

• Charity compliance requires documentation
• The prize value is significant
• Participants or regulators may request proof of fairness
• You're running public draws where trust matters
• Ontario's Electronic Raffle Systems Minimum Technical Standards or similar regulations apply
• Your organization's board or auditor needs a paper trail

For charity raffles specifically, the cost of Random.org is zero (free API tier) and the compliance benefit is substantial. There's no practical reason not to use it.

How Random.org integration works in practice

If you're using Raffle for WooCommerce, the setup takes about two minutes:

• Get a free API key at api.random.org
• Enter it in WooCommerce > Settings > Raffle
• When drawing winners, select "Random.org" as the selection method

The plugin sends a request to Random.org's Signed API for the number of random integers needed (one per winner position). No customer data leaves your site. Only a request for random numbers is sent.

The signed response, including the serial number, hash, and verification URL, is stored in your raffle's audit trail. If anyone questions the draw, you can produce the verification data.

If Random.org is unreachable (API down, network issue), the plugin falls back to random_int() automatically and logs the fallback. You're never stuck waiting for an API call to complete a draw.

Building trust beyond the algorithm

The randomness method is the foundation, but participants also care about the process around the draw. A few practices that make a real difference:

Announce your method before the draw. Post on your raffle page which selection method you're using. "Winners will be selected using Random.org's certified random number generator" tells participants you've thought about fairness before anyone asks.

Draw in public. If the raffle is for a live event, share your screen during the draw. For online-only raffles, record the screen and post the video. Transparency in the moment is worth more than documentation after the fact.

Share the verification link. When you use Random.org's Signed API, every draw produces a unique verification URL at random.org/signatures. Post that link alongside your winner announcement. Anyone can click it and independently confirm the numbers match. No trust in you or the plugin required.

Keep the audit trail accessible. In Raffle for WooCommerce, the full draw record (method used, timestamp, Random.org serial number, ticket pool size, selected tickets) is saved in the analytics dashboard. If a board member or regulator asks for documentation six months later, it's all there.

What about other raffle plugins?

We tested six WooCommerce raffle plugins for our comparison article. Here's what each one uses for winner selection:

None of the other plugins we tested offer Random.org integration, cryptographically secure selection, or a verifiable audit trail. If fairness verification matters to your use case, this is a differentiator worth considering.

The real-world impact of randomness quality

Does the randomness method actually affect who wins? In terms of outcome distribution, not meaningfully. All three methods produce statistically uniform distributions. Run any of them a million times and the frequency chart looks flat.

The difference isn't in the distribution. It's in three other areas:

Predictability. With mt_rand(), an attacker who observes outputs can predict future results. With random_int(), they can't. With Random.org, the randomness is rooted in physical phenomena that nobody controls.

Verifiability. When a charity board asks "how do we know this was fair?", your answer with mt_rand() is "trust us." With random_int(), it's "here's the code, it's cryptographically secure." With Random.org, it's "here's a signed certificate with a verification URL you can check yourself."

Regulatory acceptance. Ontario's Electronic Raffle Systems Minimum Technical Standards (AGCO, effective January 2025) require raffle systems to maintain "technical integrity, security, and accounting capability" and prevent "unauthorized alterations to Critical Game Data." Random.org's GLI certification and signed API directly address these requirements. mt_rand() doesn't.

Frequently asked questions

Is mt_rand() truly broken for raffles?

Not broken in the sense that it produces biased numbers. The distribution is fine. It's broken in the sense that the output is mathematically predictable given enough information. For a casual giveaway, this doesn't matter. For a regulated charity raffle with a $10,000 prize, the theoretical vulnerability is a real concern.

Does Random.org slow down the draw?

The API call adds 200-500ms compared to a local function call. For a single draw operation that happens once per raffle, this is imperceptible. You click "Draw Winners" and the result appears in under a second.

What happens if Random.org is down during my draw?

In Raffle for WooCommerce, the plugin falls back to random_int() automatically if Random.org is unreachable. The fallback is logged in the audit trail so you have a complete record of what method was actually used.

Is Random.org free for raffle draws?

Yes. The free API tier provides 250,000 bits per day, which is enough for hundreds of draws. A typical raffle draw requesting a few random integers uses a negligible amount of the daily quota. You'd need to run thousands of draws per day to exceed the free tier.

Can I switch methods between raffles?

Yes. The selection method is chosen at draw time, not at raffle creation. You can use Standard Random for a fun office pool and Random.org for a charity compliance draw.

Do I need Random.org for every raffle?

No. For informal giveaways, store promotions, and low-stakes draws, random_int() is more than adequate. Random.org adds value specifically when you need third-party verification, compliance documentation, or public trust in the draw process.

What does Gaming Labs International certification mean?

Gaming Labs International (GLI) is an independent testing and certification organization that verifies fairness and integrity for the gaming industry. They test everything from casino slot machines to state lottery systems. Their certification of Random.org means the random number generation has been independently verified to meet the same standards as regulated gambling operations.

Is random_int() considered "true random"?

Technically, no. It's a CSPRNG (cryptographically secure pseudorandom number generator) that uses physical entropy as its seed. The distinction is academic for most applications. What matters practically is that the output can't be predicted, even by someone with full access to the server. For the vast majority of WooCommerce raffles, random_int() provides all the security you need.

Which WooCommerce raffle plugins support Random.org?

As of March 2026, Raffle for WooCommerce is the only WooCommerce raffle plugin we've found that integrates with Random.org's Signed API for provably fair draws. Other plugins use built-in PHP random functions exclusively. If you know of another plugin that supports this, let us know.

The bottom line

For most WooCommerce raffles, random_int() is the right default. It's cryptographically secure, requires no setup, works offline, and provides genuine unpredictability. If someone asks whether your draw was fair, you can confidently say the randomness was generated from operating system entropy and can't be predicted or reproduced.

For charity raffles, public draws, or any situation where you need to prove fairness to people who don't trust you by default, Random.org is worth the two minutes of setup. The signed API gives you a verifiable paper trail that satisfies regulators, board members, and skeptical participants. It's free, it's certified by the same labs that test casino equipment, and it provides something no local random function can: independent, third-party proof.

If you're running raffles on WooCommerce, Raffle for WooCommerce is free on WordPress.org and includes all three methods. The winner selection documentation covers the full setup. For the broader picture of running a legally compliant raffle, our charity raffle guide covers the legal requirements across the US, UK, and Canada. And if you're still choosing between raffle plugins, we did a hands-on comparison of every WooCommerce option.