Random Team Generator

Paste the names, choose how many teams, and let nobody pick last.

Why picking teams by hand is the problem

Two captains taking turns is the oldest way to split a group and the worst one. It produces a public ranking of everybody present, it always ends with the same person chosen last, and the teams it makes are usually less balanced than random ones because captains pick their friends. Anyone who was ever that last pick remembers it, which is a remarkable amount of damage for a five-minute warm-up.

Randomising removes all of that in one move. Nobody is being judged, nobody has to do the judging, and the result arrives too fast to negotiate with. In a classroom or a workshop it also breaks up the clusters that form on their own, which is normally the actual reason you are splitting the group in the first place.

How the split is made even

The list is shuffled first, then dealt out one at a time to each team in turn — the same way you would deal a pack of cards. That combination matters. Shuffling alone would let you slice the list into blocks, which is random but can leave lopsided groups. Dealing alone, without a shuffle, would put everyone at the top of your list into team one, so an alphabetical or seniority-ordered list would map straight onto the teams.

Shuffle-then-deal gives you two guarantees at once. Team sizes never differ by more than one person, which is the best you can do when the numbers do not divide evenly. And every person is equally likely to end up in every team, regardless of where their name sat in the list you pasted.

The shuffle itself is a Fisher-Yates pass driven by the browser's cryptographic random number generator. That is worth a sentence because the common alternative — sorting the list with a random comparison function — is genuinely biased, produces noticeably non-uniform orderings, and appears in an enormous amount of code that looks perfectly reasonable.

Handling the leftovers

Eight people into three teams gives you three, three and two. There is no arrangement that avoids that, so the only real question is who ends up on the short team, and the answer here is that it is decided by the same shuffle as everything else rather than by list position.

If an uneven split is a problem for what you are doing, the usual fixes are to change the number of teams, to have the odd person rotate between teams each round, or to give the short team the first turn. Choosing a team count that divides your headcount cleanly is the least disruptive of the three, and you can see the sizes immediately after generating.

If someone arrives late, add their name and regenerate rather than slotting them into the smallest team. Regenerating keeps the process obviously fair; hand-placing one person is exactly the kind of small exception that people notice and remember.

Getting a different answer

Press the button again and you get a completely fresh split — nothing is remembered between runs. That is usually what you want between rounds of a game, but it does mean the tool cannot promise that somebody will not be with the same partner twice in a row. True randomness produces repeats far more often than people expect, and a run of coincidences is not evidence that anything is wrong.

If you need people to work with everyone exactly once, you want a round-robin schedule rather than a random draw. Randomness is the right tool when you want fairness and speed; it is the wrong tool when you want coverage.

For a class or a team you split regularly, keep the master list in a note and paste it in each time. Nothing here is stored on a server — no account, no saved rosters, no record of the names you entered — so the copy in your own notes is the one that survives.

Questions