"We picked the winner at random" is a claim. "Here's the entrant list, here's the seed, run it yourself" is proof. The gap between those two sentences is what this guide is about: what makes a giveaway draw provably fair, why the usual evidence (screenshots, screen recordings, a spinning wheel) doesn't get you there, and how to check a draw in a couple of minutes.

Key takeaways

A provably fair draw publishes three things: the exact set of eligible entries (or a hash committing to it), the random seed, and a deterministic method that turns seed plus entries into winners.
With those three, anyone can recompute the draw and get the same winners. Without them, you're trusting the host or the tool.
Screen recordings show that a result was displayed, not that it was random or that every entry had an equal chance.
Pickfetti draws use a seed from the operating system's cryptographic random source and an HMAC-SHA256 Fisher–Yates shuffle; the seed, entrant hash, and rules are on the public proof page at pickfetti.com/d/{code}, and /d/{code}/verify.json returns the data needed to recompute.
Provable fairness isn't about suspecting hosts of cheating; it's about giving honest hosts something better than "trust me."

Fair vs. provably fair

A draw is fair if every eligible entry had the same chance of winning. Most hosts run fair draws. A draw is provably fair if someone who wasn't in the room can confirm that it was fair, using only published information. The second property is what settles arguments, satisfies collab partners, and stops "rigged" comments before they start.

The three ingredients

1. A committed list of entries

Before any randomness happens, the set of eligible entries has to be fixed. Otherwise a host could quietly add or remove names after seeing the result. The clean way to do this is to publish a cryptographic hash of the entrant list: a short fingerprint that changes completely if even one username changes. Publishing the hash commits to the list without necessarily exposing every entrant, and it lets anyone with the list (for example, from the CSV export or the visible comments) check that the fingerprint matches.

2. A public random seed

The seed is the random number that drives the draw. It should come from a source nobody can predict or influence (an operating system's cryptographic random generator, not a hand-typed number or the current time), and it should be published after the draw. Publishing it means the "randomness" isn't hidden inside a tool; it's a value you can copy and reuse.

3. A deterministic method

Given the same seed and the same list, the method must always produce the same winners. That's what makes re-verification possible. Pickfetti uses HMAC-SHA256 keyed by the seed to generate a stream of numbers, then a Fisher–Yates shuffle over the entry list. Fisher–Yates is the standard unbiased shuffle: every ordering is equally likely. The first N positions in the shuffled list are the winners, the next few are alternates. Rejection sampling avoids the small bias you'd get from naively using modulo.

Why screenshots and recordings aren't proof

A screen recording of a picker spinning and landing on a name proves that the picker displayed that name. It doesn't show what list was fed in, whether duplicates were removed, whether the "random" step was actually random, or whether the host recorded five takes and posted the one they liked. The same is true of a screenshot of a spreadsheet's RAND() column. None of that makes recordings useless as communication, but they aren't verification. If you want your audience to check, give them something computable.

What "verifiable" looks like in practice

A Pickfetti proof page shows:

The post it was drawn from and when the draw happened.
The rules that were applied: winners and alternates, one entry per person or every comment, minimum @-mentions, required keyword, date window, exclusions, whether follows were verified.
Retrieved and reported comment counts and the eligible pool size after rules.
The winners and alternates in order, and anyone skipped by the follow check (transparently listed).
The seed and the entries hash.

The companion endpoint /d/{code}/verify.json returns the same facts as machine-readable data (seed, entries hash, algorithm description, pool size, settings) and, every time it's requested, re-runs the shuffle from the stored seed over the eligible entries and reports whether the entries hash and the published winners and alternates still match. It's a live recomputation, not a cached claim.

How to check a Pickfetti draw

Open the proof link the host shared (pickfetti.com/d/ followed by the draw code). Confirm the post is the right one and the rules match what the caption promised. This step alone catches most disputes: if the caption said "tag 2 friends" and the proof page shows minimum mentions of 0, that's the conversation to have.
Check the counts. Retrieved comments should be in the neighborhood of Instagram's displayed count (a bit lower is normal; here's why). The eligible pool is what's left after rules.
Load /d/{code}/verify.json. You'll see the seed, the entries hash, a plain description of the algorithm, the pool size, the settings, and three checks that are recomputed on the spot: entries_hash_matches, winners_match, and alternates_match. All three should be true.
Go deeper if you want to. The method is fully described (HMAC-SHA256 counter stream seeded with the published seed, Fisher–Yates over eligible entries in fetched order, first N winners, next M alternates), so a technical friend can reproduce the shuffle from the seed and the entry list. Most people never will, and that's fine; the point is that anyone could, and that the same seed and list can't produce a different answer.

What provable fairness doesn't cover

Being honest about the edges matters more than sounding perfect.

The input list. A draw is provably fair over the entries it was given. If Instagram hid comments, or the host set a keyword rule, those entries weren't in the pool. That's why the rules and counts are published too, so the pool itself is inspectable.
Things no one can see. Likes and story shares aren't public, so they can't be part of a verifiable rule. Follows are checked on the drawn winners only, and private accounts show as unknown rather than being rejected.
The host's follow-through. A provably fair draw shows who won. Whether the prize ships is on the host. Alternates drawn in the same shuffle keep even the "winner didn't respond" step transparent.

Why this matters more than it used to

Giveaways used to be small and local. Now a single post can pull thousands of entries, collab partners are splitting prizes across accounts, and audiences have seen enough fake giveaways to be suspicious by default. Publishing proof costs the host nothing and turns skepticism into a link. It also protects the host: when someone claims their friend "should have won," the answer isn't an argument, it's a URL.

Running your own provably fair draw

Paste a public Instagram post or reel link into Pickfetti, set the rules to match your caption, and draw. There's no login (it reads public comments), it's free for posts up to 500 comments, and every draw gets a proof page. Then put that link in your announcement; see how to announce a winner.

FAQ

What does "provably fair" mean for a giveaway?

That the entrant list, the random seed, and the method are published, so anyone can recompute the draw and get the same winners.

Isn't a screen recording good enough?

It shows what was displayed, not what list was used or whether the choice was random. It's fine as a communication tool, but it isn't verification.

Where does Pickfetti's randomness come from?

The seed comes from the operating system's cryptographically secure random generator at draw time. That seed drives an HMAC-SHA256 stream and a Fisher–Yates shuffle, and it's published on the proof page.

Can the host redraw until they like the result?

Each draw has its own seed and proof page, and Pickfetti's proof page shows when a draw is a redraw and lists previous winners. Drawing alternates in the first place is the honest way to handle no-shows.

How do I verify a specific draw?

Open pickfetti.com/d/{code}, check the rules and counts, then load /d/{code}/verify.json and recompute the shuffle from the seed and entries.