Team & Pair Randomizer, Explained

After reading this you will know how a Fisher-Yates shuffle turns a list of names into fair teams or pairs, how to check that the split is unbiased, and which common shuffling shortcuts quietly favor some people over others.

What this tool does

Give it a list of names. It produces one of four things: a fixed number of teams, teams of a given size, pairs, or just the names in a random order. The same engine drives all four: a full Fisher-Yates shuffle reorders the list, then the tool slices the shuffled order into groups.

Here is the hook. Suppose 12 coworkers need to split into 3 teams for a code review rotation. You could let people self-sort, but friends cluster and the loudest person picks first. Instead, drop 12 names in, ask for 3 teams, and each of the possible groupings is equally likely. Nobody can game the order, because the order is decided before anyone sees it.

When to use it, and when not to

Use it when every name should have the same chance at every position. Standups, lab partners, secret Santa draws, chore rotations, tournament seeding when you want random seeds: all of these want a flat, unbiased shuffle.

Do not use it when the outcome must be reproducible from a public seed for audit reasons, or when some entries deserve heavier odds. If one player should be picked twice as often, that is weighting, not shuffling. And if you are drawing prizes where money or fairness disputes are on the line, a browser tool is fine for the shuffle but you still need an agreed procedure so everyone trusts the result.

The shuffle behind it

Fisher-Yates walks the list from the last index down to the first. At each position i it picks a random index j between 0 and i inclusive, then swaps the two entries.

Here r is a uniform random number from the browser, i is the current position counting down from n-1 to 1, and j is the index chosen to swap into position i. Because j can equal i, an element can stay put.

The key property: this produces every one of the n! orderings with equal probability. For 12 names that is 12! = 479{,}001{,}600 distinct orders, each with probability 1/479{,}001{,}600 \approx 2.088 \times 10^{-9}. The proof is short: position n-1 gets any of n elements with probability 1/n, the next position picks from the remaining n-1 with probability 1/(n-1), and multiplying the chain gives 1/n!.

Reproducing the demo

Uneven groups and odd pairs

Numbers rarely divide cleanly. The tool spreads leftovers so team sizes differ by at most one. Split 13 people into 3 teams and you get sizes 5, 4, 4 rather than 5, 5, 3. The rule: with n people and t teams, n \bmod t teams get one extra member.

For 13 into 3, 13 \bmod 3 = 1, so exactly one team is larger. Which team gets the extra person is decided by the shuffle, not fixed, so no team position is favored across repeated runs.

For pairs, an odd count cannot split into twos. Rather than leave one person out, the tool forms one group of three. Nine names become three pairs and one triple: 4 groups, sizes 2, 2, 2, 3.

Reading and checking the result

A single run tells you nothing about fairness. Fairness is a statement about the distribution over many runs. To test it, count how often a chosen person lands on team 1 across many shuffles. With 12 people and 3 teams, that fraction should sit near 0.3333.

The count of hits over N runs follows a binomial distribution with p = 0.3333. Its standard deviation is

where N is the number of runs and p = 0.3333 is the target probability. For N = 1000, the expected count is 333.3 and \sigma = \sqrt{1000 \times 0.3333 \times 0.6667} \approx 14.9. So seeing anywhere from about 304 to 363 hits (within two standard deviations) is normal. A count of 250 or 420 would be a red flag.

Common mistakes

The gambler's fallacy shows up here constantly. If Ben landed on team 1 three runs in a row, he is not "due" for team 2. Each shuffle is independent, so his chance next run is still 0.3333. Three in a row has probability 0.3333^3 \approx 0.037, uncommon but not suspicious across dozens of sessions.

A second mistake is re-rolling until the teams "look balanced" by skill. That is a legitimate goal, but re-rolling breaks uniformity: you are now sampling from a filtered subset, and people you consider strong will cluster differently than raw chance predicts. If skill balance matters, assign it explicitly instead of pretending the result is random.

A third: reading meaning into a single split. One shuffle putting all the tall people on one team is not a bug. With 12 people the chance of any particular 4 sharing a team is 1 / \binom{12}{4} \times 3 = 3/495 \approx 0.006 for a named quartet, small but real. Rare things happen when you run often.

Related tools

If you need uniform integers rather than a shuffle, for example a random starting number or a die roll, use the Random Number Generator. When some entries should win more often, the Weighted Random Picker handles unequal odds directly. And once teams exist, the Tournament Bracket Generator arranges them into a single-elimination bracket with byes, seeded or random.

Related tools

Random Number Generator

Uniform random integers in any range, with no bias.

Tournament Bracket Generator

Single-elimination brackets with byes, seeded or random.

Weighted Random Picker

Pick from a list where some entries deserve better odds.

Are You Random? — The Oracle

Press left or right at random. The machine predicts your next press — and wins.

Dice Probability Lab

Exact odds for any dice expression — 4d6kh3, 2d20kh1…

Dice Roller (RPG Notation)

Roll 3d6+2, d20, 4d6 keep highest 3 — with statistics.