Paste a name list (one name per line), or just enter a total headcount. Set up how you want to divide the group and split everyone into groups with one click — great for classrooms, team-building activities, and small group discussions.
The grouping logic runs in two steps: first thoroughly shuffle the whole list, then hand people out to groups round-robin. The shuffle is a Fisher-Yates shuffle, implemented in the shuffle() function — starting from the last position in the list, it swaps with a random earlier position, working its way forward down to the second position. The key property of this algorithm is that it's uniformly distributed: every possible ordering is exactly equally likely, so nobody gets favored or disadvantaged just because of where their name happened to sit in the original list. A lot of people who "eyeball" a manual split, or shuffle by a crude trick like sorting alphabetically and cutting the list in half, aren't actually achieving uniform randomness — bias creeps in without anyone noticing.
After shuffling, the tool assigns people to groups with the line shuffled.forEach((name, i) => groups[i % numGroups].push(name)) — the first person goes to group 1, the second to group 2, and so on, wrapping back to group 1 once every group has had a turn. This guarantees that when the headcount doesn't divide evenly by the number of groups, the remainder gets spread across the earliest groups one at a time, so the largest and smallest group can never differ by more than one person. There's no scenario where "shuffle then slice straight down the middle" leaves the last group unusually small — that gap-of-at-most-one guarantee mentioned in the tip above isn't a coincidence, it's a deliberate property of the algorithm.
What a lot of people actually want isn't statistical randomness — it's balanced groups. A teacher might want every group to have a mix of strong and struggling students; an event organizer might want an even gender split per table. That's called stratified sampling or constrained grouping, and it's a fundamentally different operation from the plain random shuffle this tool performs. If you dump an entire class roster in and shuffle randomly, it's entirely possible — and statistically expected to happen sometimes — that one group lands mostly top students while another lands mostly quiet ones. That's the random algorithm working correctly, not a bug. If you need groups balanced by ability or some other attribute, the right approach is to manually split people into sub-lists by that attribute first (e.g. high/medium/low performers into three separate lists), run this tool's random shuffle on each sub-list separately, then merge the results — that gets you randomness within each tier while keeping the overall balance you actually wanted.
Say you're a teacher with 23 students and want 4 discussion groups. Set "Group Mode" to "By Number of Groups," enter 4 in the field next to it, paste in the 23 names, and click "Divide Into Groups." 23 divided by 4 is 5 remainder 3, so you'll get 3 groups of 6 and 1 group of 5 — exactly the "at most one person difference" the tip describes. If instead you care more about a fixed group size of 5 and don't mind however many groups that produces, switch to "By Group Size" and enter 5 — the tool calculates you need 5 groups (23÷5 rounded up), with the last group ending up smaller than the rest. The difference between the two modes is simply whether you're fixing the number of groups or the size of each group first — pick whichever matches your room layout or activity format.
It's genuinely random. Grouping uses the Fisher-Yates shuffle algorithm, built on JavaScript's Math.random(), where every possible ordering is theoretically equally likely — no bias toward people in any particular position in the original list. Click "Divide Into Groups" again on the same list and you'll get a different split every time.
No. The entire grouping calculation runs as JavaScript locally in your browser — there's no code on this page that sends the list or the results to a server. Close the tab or refresh the page and everything is gone; nothing is retained.
Groups come out perfectly even only when the headcount divides evenly by the number of groups. When it doesn't, the tool distributes the leftover people one at a time across the earliest groups, so the largest and smallest group differ by at most one person — that's deliberate fairness logic, not a bug.
Not in the current version — every run performs a uniform random split across the entire list with no constraints. If you need that (say, keeping two students who don't work well together in different groups), the workaround is to manually pull those people out first, shuffle everyone else, then manually place the excluded people into different groups afterward.
The tool auto-generates a placeholder list — "Member 1," "Member 2," and so on — based on the headcount you entered, then runs the same random split on it. This is handy when you just want to preview how a split would look before you have an actual name list, like figuring out group sizes for a venue before registrations come in.