Method and limits
How random team generation works
The generator separates three decisions: how capacities are calculated, how names are shuffled, and how optional rules restrict assignment.
1. Prepare the roster without changing its labels
Each non-empty line becomes one participant. Leading and trailing spaces are removed; accents, non-Latin scripts and emoji remain. Possible duplicates are flagged for you to keep or remove.
The limits are 500 names, 120 visible characters (grapheme clusters) per name and 50,000 in total. CSV imports read the first comma-separated column, with one participant per line; quoted fields containing line breaks are not supported. Names are rendered as text, never as HTML.
2. Calculate team capacities
With “number of teams,” the roster is divided so capacities differ by at most one. For 10 people and 3 teams, the capacity pattern is 4–3–3. With “people per team,” the target size determines how many non-empty teams are needed.
This is an even-size rule only. It says nothing about ability, experience, role, gender, or social fairness.
3. Seed and shuffle the full list
Without optional rules, the browser creates an initial seed from Web Crypto. A versioned deterministic generator then drives an unbiased integer selection and a Fisher–Yates shuffle before participants are assigned to the calculated capacities.
Using the same ordered input, settings, rules, seed, and engine version reproduces the result. A new seed gives a new draw; the draw ID is a reference, not evidence that teams are skill-balanced.
4. Resolve and verify optional rules
Together groups are treated as blocks. Apart pairs cannot share a team, and fixed leaders occupy separate teams. The most restricted items are placed first and a bounded backtracking search explores assignments in a seed-controlled order.
Every output is checked after solving. Known impossibilities receive a specific explanation. If the bounded search is exhausted, the tool reports its solver limit rather than claiming that no mathematical solution exists.
What is tested—and what is not promised
Core invariants are that every accepted participant appears exactly once, size rules hold, selected constraints hold, and reproducibility is stable for the same engine version. Small cases can be exhaustively checked and larger ones sampled for obvious implementation bias.
A random or constrained result is not a professional assessment, an accessibility decision, or a guarantee of fair performance. Balanced teams would require separate, explicit data and a documented objective.