Random Team / Name Picker Generator

Paste the names into the text box, one per line or separated by commas. Blank lines and extra spaces around a name are ignored. The Total entries figure confirms the count, so for this example it should read 23 before you go any further.

Watch the Duplicate names found figure. The check ignores capitalisation, so "Sam" and "sam" count as a duplicate. Duplicates are flagged but not removed, and a name listed twice is shuffled as two separate entries: it can fill two seats on the same or different teams, and in winner mode it has twice the chance of being drawn. Delete the extra copy unless that is what you intend.

Set Mode to Split Into Teams and Number of teams to 4. The results show Team 1 (6), Team 2 (6), Team 3 (6) and Team 4 (5), each with its member list. Press Draw Again for a completely new shuffle.

Every change to the inputs also triggers a fresh draw: editing a name, switching mode or changing the team count reshuffles the list. Settle the list and settings first, then treat the next draw as the one that counts, ideally with the group watching.

In Pick Winners mode, set Number of winners. With 20 entries and 3 winners, the result shows three names in drawn order and the other 17 under Not picked. Each entrant had exactly a 3 in 20 (15%) chance of being among the winners, and because the order is random too, you can hand out first, second and third prizes in the order shown.

Shuffle. The tool uses the in-place Fisher-Yates shuffle in the form published by Richard Durstenfeld as "Algorithm 235: Random permutation" in Communications of the ACM (1964):

• For i from the last position down to 1: choose j = floor(random × (i + 1)), a whole number from 0 to i, and swap the names at positions i and j.

Each name is placed into its final position exactly once, and at step i there are exactly i + 1 equally likely choices. Multiplying those choices gives N × (N − 1) × … × 2 = N! equally likely paths, one for each possible ordering, so every permutation has probability exactly 1/N!.

Winners. Winners = the first W names of the shuffled list, where W is clamped between 1 and the number of entries. That is sampling without replacement, so nobody can win twice in one draw, and each person's chance of being picked is W ÷ N.

Teams. The name at shuffled position i goes to team (i mod K) + 1. The team count is capped at the number of names, so no team is ever empty. Team sizes follow directly: ⌊N ÷ K⌋ for every team, plus one for teams 1 through N mod K. Note what that implies: the larger teams are always the lowest-numbered ones. Which people fill them is random; which team label gets the extra seat is not. Since the labels themselves mean nothing, this does not make any person more or less likely to be on a bigger team.

Why not sort with a random comparator? A common shortcut is list.sort(() => Math.random() − 0.5). It is biased for a structural reason: a comparison sort makes a limited number of comparisons, each a 50/50 coin flip, so every outcome's probability is a multiple of 1/2^k. For three names each ordering needs probability 1/6, which no such fraction can equal. In a test of 600,000 three-name shuffles run in Node.js, the sort shortcut produced two of the six orderings about twice as often as the other four, while this page's Fisher-Yates function produced all six about equally.

With 10 names and 3 teams, 10 ÷ 3 = 3 remainder 1, so the teams are 4, 3 and 3, with the four-person team always shown as Team 1. Now the uneven seat matters more: 60% of people land on a three-person team and 40% on the four-person team, compared with roughly 78% and 22% in the 23-person example.

The chance that two particular people end up together is the number of ways to seat them as a pair on the same team divided by all the ways to seat them: (4×3 + 3×2 + 3×2) ÷ (10×9) = 24 ÷ 90 = 26.67%. That is noticeably higher than the 21.74% in the 23-person case, because fewer teams of similar size mean more shared seats. Two even teams of 4 from 8 people push it to 42.86%, and 31 people in 6 teams bring it down to 13.98%.

These percentages are a useful sanity check when a group complains that "the same people always end up together." With only two or three teams, repeat pairings across several draws are expected, not a sign that anything is wrong.

Fairness in the algorithm only helps if the process around it is fair. Finalise the entry list before anyone draws, and share it, so nobody can be added or removed after the result is known. Do one draw with the group watching or on a shared screen. Discarding results until a preferred one appears defeats the shuffle entirely, and the tool cannot detect it.

The tool does not remember earlier draws. For rotating chores or multi-round prizes where nobody should be picked twice, remove each winner from the list before the next draw.

Randomness also has a technical ceiling. The browser's Math.random() is not cryptographic: Google's V8 engine, used by Chrome and Edge, documents it as the xorshift128+ generator with 128 bits of internal state. Since 34! is about 2.95 × 10^38 and 2^128 is about 3.40 × 10^38, lists of 35 or more names have more possible orderings than the generator has starting states, so not every ordering can occur. No individual name is disadvantaged by this for a classroom or office draw, but it is one reason regulated lotteries and prize promotions use audited random-number systems.

This picker balances team sizes, not skills. It knows nothing about ability, age, experience or who should not be paired, so a random split can put the three strongest players on one team. For balanced competitive teams, seed the strongest players across teams by hand first and randomise the rest.

Commas always separate entries, so a name typed as "Smith, John" becomes two entries, Smith and John. Use one name per line in that format. There is no weighting, so an entrant cannot have extra tickets except by listing the name more than once.

Results are not saved or logged, and the randomness is not cryptographically secure. Do not use it to generate passwords, security tokens or anything where predictability would be a risk, and do not rely on it as the official draw mechanism for a sweepstakes or lottery that is governed by law or regulation.

When the thing you need is a random number rather than a random order of names, the Random Number Generator draws values in a range you choose. The UUID Generator uses the browser's cryptographic randomUUID function where it is available, the stronger source that identifiers need. The Password Calculator is the tool for secrets. This picker is unseeded and gives a new result on every draw, but its shuffle uses the browser's ordinary Math.random generator, which is fine for splitting a group and should never be used to make a password. The Random Number Generation guide explains the difference between seeded, browser and cryptographic randomness, and when each is appropriate.