How to Run a Provably Fair Draw in 5 Steps (and Prove It Afterwards)

A draw is only useful if people believe it. The moment a winner is announced, the first question is always the same: did you rig that? This guide covers how to run a draw that survives that question — and how to prove it after the fact.

The Five Steps

Step 1: Define the Eligibility Rule Before Anyone Enters

Write the rule down and publish it before entry opens. Who qualifies? Is one entry per person enforced? Are employees or family members excluded?

This is the step that decides whether a dispute is about randomness or about rules. Most “unfair draw” complaints are really rule disagreements, and no randomizer fixes those.

Step 2: Freeze the Pool Before Drawing

Close entry, then take a snapshot of the final list. Don’t draw from a list that can still grow — someone who missed the deadline could claim they would have entered.

If you use photo import, this is where you read the extracted names carefully. A misread name is a legitimate challenge, and it’s much cheaper to fix before the draw.

Step 3: Turn On Duplicate Protection

Two entries from the same account defeat the point of the pool. Enable Prevent Duplicate Names so the tool filters repeats. If your rules allow weighted entries or multiple tickets, use the Weighted Raffle instead — it makes the weighting explicit rather than accidental.

Step 4: Set Winner Count and Removal Behavior

For multi-prize draws, set the number of winners before drawing and enable Remove Winner from List so the same person can’t win twice.

For sequential single-prize draws — draw, announce, draw again — removal behavior should be off during the announcement and adjusted per your rules. Decide this before you start, not in the middle when someone is watching.

Step 5: Draw, Record, Publish

Run the draw while the pool is visible. Save the screenshot of the result panel including the participant list. Publish both together.

That screenshot is your evidence. It shows who was eligible at the moment of the draw.

Why the Result Is Actually Random

Most tools use Math.random() — a pseudo-random number generator. It’s fast, but it’s deterministic: its internal state can, in principle, be reconstructed to predict every future result. For a coffee-break raffle nobody cares. For a prize, a paid promotion, or anything with legal weight, it’s the wrong foundation.

RandomSelect uses the browser’s crypto.getRandomValues(), which draws entropy from the operating system’s cryptographic source. The properties that matter:

• Independence — each draw is unrelated to previous and future draws
• No seed to manipulate — the result can’t be steered by user input or timing
• Uniform distribution — every name has exactly equal probability

You can read the platform’s own audit page for the full explanation: How Fairness Is Verified.

The Detail That Ends Most Arguments

The animation is decorative.

The winner is computed before the wheel starts moving. The animation then plays toward that predetermined outcome.

This matters because it means nobody can influence the result by timing a click, by watching how fast the wheel is turning, or by judging when to “tap” the button. There is no timing input to exploit, because timing isn’t an input at all.

If someone claims a fast click produced a different winner than a slow one, they can test it: run the same draw a hundred times with different click timings. The distribution won’t shift.

Making It Publicly Verifiable

For high-stakes draws — brand campaigns with prizes — publish these four things:

1. The eligibility rules, written before entry opened
2. The final frozen participant list
3. The random selection method — name the tool and note it uses cryptographic RNG
4. The recording — video or screenshot showing the draw with the list visible

That’s a complete audit trail. Anyone can check that the rules were published first and that the recorded list matches the pool you claim was frozen.

Objection Handling

“The animation was too fast to verify.” Point out the winner is fixed before the animation, and offer the screenshot showing the list.

“Your tool could have picked a different order.” Then run the draw again on the same list. Any randomization the tool applied is visible as reordering, which anyone can observe without inspecting code.

“I never entered.” This is a rule problem, not a randomness problem. Point to the published eligibility rule and the entry timestamps.

“The names were misread from the photo.” Anonymize and republish the corrected list before the draw. This is exactly why photo import should be verified before the freeze, not after.

Common Mistakes

• Drawing from a live list — entry must close first
• No duplicate protection — multi-entry wins are the most common dispute
• Announcing prize count mid-draw — decide before, record during
• Publishing results without the list — the screenshot is the proof
• Retrying an inconvenient result — a retried draw is a new draw, and claiming the old one is void invites exactly the suspicion you’re trying to avoid

Ready to run one? Open the Lucky Draw or the Wheel of Names — both use the same cryptographic randomness, so the fairness reasoning applies identically.

RandomSelect.net — draws people can verify.