Real-world workflow
Use CaseShuffle a Team Draw or Raffle List
Randomize names for a fair draw, then pick from the top.
The problem
Somebody has to win, and everyone needs to trust how they won. Whether you are drawing a raffle at a team offsite, choosing who gets the last conference ticket, or ordering entrants for a giveaway, picking by hand invites accusations of favouritism. A shuffle removes the human thumb from the scale: randomise the whole list, then read winners from the top in one pass.
Who this is for
Team leads and event organisers running internal draws, community managers doing small giveaways, teachers assigning random order, and anyone who needs a draw that is quick to run and easy to explain.
Before and after
Paste your entrants, one per line:
Priya
Marco
Ada
Wei
Sofia
Ken
After a single shuffle:
Sofia
Ken
Priya
Ada
Marco
Wei
If you are awarding three prizes: Sofia (1st), Ken (2nd), Priya (3rd).
There is no second draw — the shuffle already ranked everyone.
Steps
- Open Shuffle List.
- Paste each entrant on its own line.
- If you want a fresh order, click Re-shuffle — but only before you reveal anything to participants.
- Read winners from the top: line 1 is first place, line 2 is second, and so on.
- Copy the shuffled list and share it (or screenshot it) as a record of the draw.
Multiple prize tiers with groups
When prizes come in tiers with several winners each — say five “runner-up” spots — shuffle first, then split. Paste the shuffled output into List Splitter, choose Into K groups, and set K to the number of tiers. Group 1 is your top tier, group 2 the next, and so on. Because you shuffled before splitting, each group is a random slice rather than a chunk of the original ordering.
How to verify the draw
Fairness depends on the shuffle being complete and lossless. Check that the output line count equals the entrant count so nobody was dropped or duplicated. Blank lines are removed by default, so a lower count that matches the number of blanks you pasted is expected. To make the draw transparent, run it on a shared screen and keep the copied result — that way the order is fixed and visible to everyone at the moment of the draw.
Edge cases and common mistakes
- Duplicate names. If two different people share a name, add a distinguisher
(
Priya S,Priya M) before shuffling, or you will not be able to tell winners apart. - Accidental extra chances. The same entrant listed twice has double the odds. Dedupe with Remove Duplicates from List unless multiple tickets are intended.
- Weighted entries. If entrants earned different numbers of tickets, list each entrant once per ticket before shuffling.
- Sorting after shuffling. Do not run the shuffled list through an alphabetical Text Sorter pass — that throws away the random order. Sorting and shuffling are opposite operations here.
Handling absentees and no-shows
A common awkward moment: the drawn winner is not in the room or turns out to be ineligible. Decide the rule before you draw, and pick one that stays fair. The cleanest option is to draw the full ranked order in one shuffle and announce that if a winner can not claim, the prize passes to the next eligible line down. Because the whole order came from a single shuffle, moving to the next line is not a re-draw — it was already decided. What you should not do is re-shuffle the remaining names after a no-show, because you have now seen part of the result and any fresh shuffle is influenced by that knowledge.
Announcing the result
Run the draw on a shared screen and copy the shuffled list into the channel where the announcement lives. Keeping the copied order is your receipt: it shows every entrant was included exactly once and that winners were read top-down from one draw. This small habit heads off “how was that decided?” questions after the fact.
Privacy and fairness caveats
Shuffle List is client-side, so entrant names never leave your browser. On fairness, be precise: the shuffle is Math.random-based (pseudo-random) and is appropriate for internal team draws and casual raffles. It is not suitable for regulated promotions, high-value prizes, or any draw with legal weight — those require a verifiable, auditable, or cryptographically secure random process. Also remember the core rule: a re-shuffle after a result has been seen breaks the fairness of the draw. Shuffle, reveal, commit.
Related next steps
- Just need one quick pick? See Shuffle List as a Random Picker.
- Building random groups for something other than prizes? Combine Shuffle List with Split List into Groups.
Related
Frequently Asked Questions
How do I draw multiple prize tiers?
Shuffle once, then read from the top: the first line is first prize, the second line is second prize, and so on. One shuffle produces the whole ranked result, so you never re-draw between tiers.
Can I split winners into prize groups instead?
Yes. Shuffle first, then paste the shuffled list into List Splitter using Into K groups (one group per tier). Splitting before shuffling would just group people by their original order, which is not random.
Is re-shuffling allowed?
Re-shuffle freely before you reveal anything. Once a result is shown to participants, re-shuffling undermines fairness because you are effectively choosing among outcomes you have already seen.
Is this random enough for a real prize draw?
It uses a Fisher-Yates shuffle with Math.random — genuinely fine for internal team draws and informal raffles. It is NOT suitable for regulated, high-value, or legally binding prize draws, which need a verifiable or auditable random method.
Are the names sent to a server?
No. Shuffle List runs entirely in your browser, so participant names stay on your device.