Seeded and Reproducible Draws
A draw anyone can re-run is a draw anyone can check — and a draw anyone can predict.
A seeded draw produces the same result every time from the same seed. That sounds like a defect and is, for one specific purpose, the most valuable property a draw can have: it is the only way to let someone else check your result.
The trade is total. A draw anyone can reproduce is a draw anyone can predict, so a seeded generator is exactly the wrong choice everywhere unpredictability matters and exactly the right one where verifiability does.
This page covers how seeding works, how to run a verifiable draw, and the specific mistake that makes a published seed prove nothing.
What a seed is
A seed is the starting state of a deterministic generator. Feed the generator a number, and it produces a sequence of values; feed it the same number again, and it produces the identical sequence, on any device, in any browser, at any time.
A human-readable seed is hashed into that number first. A phrase like `amber-flint-glade-472` goes through a hash function to produce a 32-bit integer, and the generator starts from there. The hash is deterministic, so the same phrase always gives the same integer and therefore the same sequence.
Words rather than a raw number matter more than they look. A seed has to survive being read aloud on a stream, typed by a sceptical viewer, and written on a whiteboard. `amber-flint-glade-472` does that; `2947183624` gets transcribed wrongly.
Running a verifiable draw
The basic workflow is four steps, and its strength depends entirely on the order.
First, freeze the entrant list and publish it. Second, publish the seed. Third, run the draw. Fourth, publish the result. Anyone can then repeat step three with the published inputs and confirm they get the published output — without trusting you, the site, or anything except the reproducibility of the generator.
That is a genuinely strong property. It converts "take my word for it" into "here is the computation, run it yourself", which is the only form of fairness claim that survives a determined sceptic.
A published draw, in order
- 1. Post the frozen entrant list. Nobody can be added after this point.
- 2. Post the seed: 'amber-flint-glade-472'.
- 3. Run the seeded shuffle. The first name is the winner.
- 4. Post the result. Anyone can now re-run steps 1–3 and check step 4.
The mistake that makes it prove nothing
The workflow above has a hole, and it is the one people fall into: if you choose the seed after seeing what each seed produces, publishing it proves nothing at all.
Nothing stops an organiser trying two hundred seeds, finding the one that makes their friend win, and publishing that seed alongside the entrant list. Every step of the verification succeeds. The result is reproducible, the arithmetic checks out, and the draw was rigged.
This is why the seed must be committed to before the draw, and preferably before the entrant list closes. Publishing it in advance removes the search entirely — you cannot pick a favourable seed if you announced it before you knew who was entering.
Commit-and-reveal, the stronger version
Publishing the seed in advance has an obvious problem: everyone can compute the winner before entries close, which changes behaviour. The standard solution is to commit to the seed without revealing it.
Publish a cryptographic hash of the seed before the draw. A hash is easy to compute and infeasible to reverse, so the commitment reveals nothing about the seed while making it impossible for you to change it later — any other seed would produce a different hash.
After the draw, publish the seed itself. Anyone can hash it, confirm it matches the commitment you published beforehand, and then re-run the draw. That combination proves both that the seed was fixed in advance and that the result follows from it, which is the full property people mean by "provably fair".
- Before: publish hash(seed). Reveals nothing, and locks you in.
- After: publish the seed. Anyone can hash it and check it matches.
- Then: anyone can re-run the draw from the seed and the frozen list.
- This defeats seed-shopping, which plain seed publication does not.
Where seeded draws are the wrong choice
Anywhere the outcome must be unknowable in advance. A seeded generator gives its entire future to anyone holding the seed, so it must never be used for passwords, tokens, or any draw where a participant acting on foreknowledge would gain something.
It is also wrong wherever nobody is going to check. The whole cost of a seeded draw is that it is predictable; if no one is verifying, you have paid that cost for nothing and should use the unpredictable generator instead.
The practical rule is simple: seeded when a sceptic will re-run it, unpredictable otherwise. Most draws are the second case, which is why this site uses a seeded generator on exactly one page.
Frequently asked questions
What does a seed actually do?
It sets the starting state of a deterministic generator. The same seed produces the same sequence of values on any device, at any time.
Why use words instead of a number?
Because a seed has to survive being read aloud, typed by someone else, and written down. A word phrase does that; a ten-digit number gets transcribed wrongly.
Does publishing the seed prove the draw was fair?
Only if you published it before the draw. Otherwise you could have tried hundreds of seeds and published the one that gave the result you wanted.
What is commit-and-reveal?
Publish a hash of the seed before the draw and the seed itself afterwards. The hash locks you in without revealing anything, which defeats seed-shopping.
Why not just publish the seed in advance?
Because everyone could then compute the winner before entries closed, which changes who enters. The hash commitment gives the same guarantee without that.
Is a seeded draw less random?
Its output is well-distributed and every ordering is reachable. It is not unpredictable, which is a different property and the one it deliberately gives up.
When should I not use a seeded draw?
Anywhere the outcome must be unknowable in advance, and anywhere nobody will actually verify it. You pay predictability for verifiability; do not pay it for nothing.
Does the same seed work on someone else's device?
Yes, provided they use the same generator. The hash and the algorithm are both deterministic and platform-independent.
Tools that use this
Random Seed Generator
Generate a seed, then reproduce the exact same draw from it — the auditable kind of random.
Raffle & Giveaway Picker
Paste your entrant list and draw a fair, verifiable winner — built for streamers.
Order Randomizer
Shuffle any list into a fair random order — presentation order, turn order, anything.
Related guides
Provably Fair Draws: Commit and Reveal
Publish a hash before the draw, publish the seed after. A worked example, start to finish.
How to Prove a Draw Was Fair Afterwards
What evidence actually convinces someone who was not in the room when you drew.
Pseudo-Random vs Cryptographic Randomness
Two generators, two guarantees, and the surprisingly small list of cases where the difference bites.