Random Picker & Team Generator

Why we don't use Math.random

Most web applications that need randomness use Math.random(). For simple games or picking a color, it's perfectly fine. But for drawing winners, it has two flaws.

First, Math.random is not cryptographically secure. It uses a pseudorandom number algorithm internally, meaning its next output can be predicted if enough previous outputs are observed. Indeed, studies have successfully restored the internal state of a browser's Math.random. Second, the specification does not strictly guarantee uniformity, and implementations differ between browsers.

That's why this tool uses crypto.getRandomValues(). It pulls values from the operating system's entropy pool, making it unpredictable. It was created for the very purpose of generating cryptographic keys.

Modulo Bias — What Most Pickers Get Wrong

Even with good random numbers, fairness can be broken in the final step. A common method is to take a random number from 0 to 4,294,967,295 and use the remainder after dividing it by the number of participants.

The problem is that 4,294,967,296 is not always perfectly divisible by the number of participants. For example, with 3 participants, the case where the remainder is 0 occurs exactly one more time than the cases for 1 or 2. This gives the people at the beginning of the list a very slight advantage.

While the difference is tiny and usually ignored, there's no reason for a tool that claims to be "perfectly uniform" to leave this bias in. This tool eliminates it using rejection sampling: if a generated value falls into the non-divisible trailing range, it's discarded and a new one is drawn.

// Biased — earlier items have a slight advantage
var bad = crypto.getRandomValues(new Uint32Array(1))[0] % n;

// Unbiased — discard and redraw values outside the uniform range
function randInt(n) {
  if (n <= 1) return 0;
  var limit = Math.floor(4294967296 / n) * n;
  var buf = new Uint32Array(1);
  do { crypto.getRandomValues(buf); } while (buf[0] >= limit);
  return buf[0] % n;
}

The Real Problem with Giveaways Isn't the Random Number, It's Trust

To be honest, no matter how perfect the random numbers this tool uses are, there's no way to prove it to the participants. A screenshot of the results can be easily faked, and saying "we used crypto.getRandomValues" means nothing to them.

Disputes over drawings don't come from the quality of the random number. They come from the suspicion that "the organizer just re-ran it until their friend won." This is a problem to be solved with procedure, not technology.

• Publish the list of participants first. Before the draw, post the list of names/nicknames in an announcement, and then paste that exact list into the tool. If you only announce the results, no one knows if you added someone who wasn't on the original list.
• Record the drawing process. A screen recording that captures everything from pasting the list to the final result serves as evidence that you didn't "re-roll". A live stream is even better.
• Set the rules in stone beforehand. Announcing "how many, when, and with what tool" in advance reduces suspicion that you changed the conditions after the fact.
• Pick runners-up at the same time. A common cause of disputes is having to re-draw because a winner is unresponsive. It's cleaner to pick 3 winners + 2 runners-up all at once and announce them in order.
• If you're running a drawing large enough that participants need to be able to verify it themselves, a browser-based tool like this is not enough. You'll need a different design, such as one that uses a publicly available value as a seed.

Four Modes: When to Use What

In "Pick" mode, if you set the number to pick to be equal to the total number of items, the result is the same as "Shuffle Order". However, the Shuffle mode doesn't display probability statistics, making it a better fit for uses like determining presentation order.

"Allow duplicate items" can be confusing. When OFF, one person can only be picked once (for giveaway winners). When ON, the same person can be picked multiple times (like rolling a die, where each draw is independent). If you're picking giveaway winners, you should almost always leave this OFF.

Handling Uneven Team Sizes

If you divide 11 people into 3 teams, you'll get teams of 4, 4, and 3. The question is, "Who gets to be on the team of 3?" If you simply slice the list from the top, the last team always loses out.

This tool first shuffles the entire list, then assigns members to teams one by one in a round-robin fashion. This ensures the size difference between any two teams is at most one, and which team gets an extra member is also determined randomly by the shuffle.

• If you leave the team names blank, they will be automatically named Team 1, Team 2, Team 3, etc. If you provide comma-separated names like "Red, Blue, Green", those names will be used.
• If you provide fewer team names than the number of teams, the remaining teams will be given automatic numeric names.
• This tool cannot perform skill-based balancing; it is purely random. If skill balance is needed, a practical approach is to create separate groups for high, mid, and low-skilled players, run the tool on each group, and distribute the members into the final teams.
• The message below the results tells you how the teams were divided. If it's an even split, it will say "with exactly N members each." If not, it will specify how many teams have how many members.