Tool
Secret Santa Generator
Generate fair Secret Santa pairs — nobody draws their own name, nothing stored.
Secret Santa Generator
Enter your group's names, and get fair Secret Santa gift-giving pairs where nobody ever draws their own name -- with nothing about who has whom stored or visible to the organizer afterward.
The organizer sets it up; each participant can then reveal only their own match.
It handles exclusion rules too, like keeping couples from drawing each other.
How the Secret Santa Generator works — and why it's fair
This needs more than a plain shuffle -- a Secret Santa assignment is what's called a derangement: a random permutation where no participant is assigned to themselves. The tool performs a Fisher-Yates shuffle using crypto.getRandomValues and checks for any self-matches (someone assigned their own name); if a self-match occurs, which happens roughly 37% of the time with a naive shuffle for even a modest group size, it re-shuffles and checks again until it lands on a valid derangement with zero self-matches.
The same rejection-and-retry approach handles exclusion pairs too -- say a couple shouldn't be matched with each other -- by re-shuffling whenever a forbidden pairing occurs, until a valid assignment satisfying every constraint is found. Because the whole process runs client-side, the organizer never has to see or store the final pairing list; each participant can be shown only their own individual match.
That roughly 37% self-match rate is worth knowing about -- it comes from a well-known result in probability (as group size grows, the chance a random permutation has at least one self-match converges to about 1 minus 1/e, or roughly 63%, meaning a valid derangement happens on the first try only about 37% of the time), which is exactly why this tool needs the retry loop the plain team generator's shuffle doesn't.
One more mathematical note: as group size grows beyond a handful of people, that roughly 63% self-match probability for a single naive shuffle stays fairly stable rather than climbing further -- it converges toward 1 minus 1/e regardless of whether the group is 10 people or 100, which is a genuinely elegant (if slightly counterintuitive) result from permutation probability theory.
Where this replaces the spreadsheet-and-hat method
Office holiday gift exchanges, where HR or an organizer needs a fair draw without personally knowing (and accidentally leaking) who has whom. Family gift exchanges spread across different households, where a physical hat draw isn't practical. Remote or distributed team gift swaps, where everyone needs their match delivered privately rather than announced in a group channel.
Some friend groups also use it for White Elephant-adjacent draw orders where a private, no-repeat pairing needs to be set up ahead of the actual gift exchange event.
For simply splitting a group into teams rather than generating no-self-match gift pairs, the team generator is the right tool; for reordering a full list without the self-avoidance constraint, use the list randomizer.
Some multi-family friend groups use it across households for a shared holiday gift exchange, relying on the private per-person reveal specifically because not everyone will be in the same room when assignments are generated.
Frequently asked questions
How does it guarantee no one draws their own name?
It re-shuffles and re-checks until it produces a valid derangement -- a random assignment with zero self-matches -- rather than accepting the first shuffle regardless of self-matches.
Can I stop a couple from being matched with each other?
Yes -- set them as an excluded pair and the tool re-shuffles past any assignment that would match them together.
Can each person see only their own match, not the whole list?
Yes -- that's the intended flow, since the whole draw runs client-side without the organizer needing to see the final pairing.
Is the pairing list saved anywhere after I close the page?
No -- nothing is transmitted or stored server-side; the assignment exists only in that browser session unless you export or share it yourself.
Why does this need a retry loop when the team generator doesn't?
A plain shuffle has roughly a 63% chance of accidentally matching at least one person to themselves in a group of any real size, so this tool re-shuffles until it finds a valid derangement -- a constraint the team generator's plain grouping doesn't have.
Does group size affect how long the retry loop takes?
Not meaningfully -- because the self-match probability converges to a stable rate regardless of group size, the number of retries needed stays small and the whole process still completes effectively instantly.
Can I add more exclusion pairs beyond just one couple?
Yes -- each exclusion pair narrows the valid outcomes further, and the tool keeps re-shuffling until every constraint is satisfied at once.