Random team generator
Press Draw to see the result
Paste your list, choose how many teams you want or how many people go in each, and the names are shuffled and then dealt out one at a time. Eleven people into three teams gives four, four and three, because dealing spreads the remainder instead of dumping it on the last team.
How to make random teams
The two modes answer different questions and are not interchangeable. Fixing the number of teams suits a fixed set of slots: four workshop tables, two sides of a pitch, three breakout rooms. Fixing the size suits an activity designed around a group of a particular size, where however many people turn up have to be arranged into threes or fours.
Dealing rather than slicing is the mechanism behind the even split. A naive implementation cuts the shuffled list into consecutive chunks, so eleven people into groups of four come out 4, 4, 2 and 1. This one shuffles and then deals a name to each team in turn, over and over, so the counts can never differ by more than one. In size mode that makes the number you type a ceiling rather than a target: ask for four per team with eleven people and you get three teams of 4, 4 and 3, not two full teams and a straggler.
On the randomness, there are two different generators here and the difference matters. Leave the seed box empty and each swap in the Fisher–Yates shuffle draws from crypto.getRandomValues with rejection sampling, so every arrangement of your list is genuinely equally likely. Type a seed and a small deterministic generator takes over instead, because reproducibility and unpredictability are opposites. That generator holds 32 bits of state, which is 4,294,967,296 possible starting points. Twelve names have 479,001,600 orderings and fit inside that comfortably; thirteen names have 6,227,020,800 orderings and do not, so a seeded draw of thirteen or more people can never produce most of the possible team lists. Nothing about a particular draw is biased by this, and for settling an argument about a five-a-side line-up it does not matter at all, but the guarantee genuinely is weaker with a seed than without one.
A seed also collides. Two different words can hash to the same internal state and produce identical teams, which is harmless here and occasionally confusing.
Fair and balanced are different things, and this tool only offers the first. A uniform draw treats every arrangement as equally likely, including the one that puts your four best players together. Over enough draws that is exactly what fairness means, and on any single Saturday morning it is what people complain about. If the point is a competitive game rather than a neutral procedure, sort the list into tiers first, draw each tier separately, and hand out one name from each: the draw stays random inside a tier and the strength ends up spread. Redrawing until the teams look right does the opposite. It is a filtered draw dressed as a fair one, and the filter is your own judgement, which is the thing you were trying to take out.
What the deal does not know is anything else about the people in it. It has no memory of last week, so it cannot avoid repeating a pairing. It cannot keep two people apart, because a constraint like that turns a shuffle into a matching problem with a different algorithm behind it. And it has no view on who should captain what. Draw again as often as you like, or move one name by hand afterwards and say that you did.
What people use it for
- Splitting a five-a-side squad when the same pairs always end up together
- Filling a fixed number of workshop tables from whoever turned up
- Making a draw the losing side can check afterwards from the seed
- Dividing a class for a quiz without appointing captains
- Building tiered teams by drawing each tier separately
- Producing an assignment nobody in the room chose
Questions
Dealt round-robin, so team sizes differ by at most one. Eleven into three is 4/4/3, never 5/3/3.
You get three teams of 4, 4 and 3. In size mode the number you type is a ceiling, and the leftovers are spread rather than left as a short team at the end.
Number of teams when the slots are fixed, such as four tables or two sides. Size when the activity needs groups of a particular size and the turnout varies.
With the seed box empty, yes: it is a Fisher–Yates shuffle where every swap draws from crypto.getRandomValues with rejection sampling, so every arrangement is equally likely.
A small deterministic generator replaces the cryptographic one, because a reproducible draw cannot also be unpredictable. The same seed and list always give the same teams.
Not for any single draw, but the guarantee is weaker. The seeded generator has 32 bits of state, about 4.29 billion possibilities, so from thirteen names upward it cannot reach every one of the 6.2 billion orderings.
Twelve names, whose 479 million orderings fit inside the generator’s 4.29 billion states. From thirteen upward some arrangements become unreachable.
Yes. The seed is hashed into a 32-bit value, so collisions exist. It changes nothing about the fairness of either draw.
Sharing it is the whole point. Publish the list and the seed and anyone can reproduce the draw and confirm nobody re-rolled it.
No. It has no idea who is good. A uniform draw will cheerfully put your four strongest players on one team, because that arrangement is exactly as likely as any other.
Split the list into tiers yourself, draw each tier separately, and take one name from each tier per team. Randomness stays inside a tier and strength is spread across them.
It stops being a random draw. You have added a filter, and the filter is your own opinion about who should play together, which is the thing the draw was supposed to remove.
Not automatically. Draw again, or move one name by hand and say so. Constraints turn a shuffle into a matching problem, which is a different and much slower algorithm.
No. Every draw is independent, so repeats happen. Avoiding them across weeks needs a rotation schedule rather than a draw.
Thousands of names are fine. Everything runs on your device, and the shuffle is linear in the length of the list.
No. It lives in the page while you are on it and is gone when you close the tab.