How to Randomly Pick One NFL, NBA, or MLB Team Without Favoring Any of Them
Picking fairly among the NFL’s 32 teams, the NBA’s 30 teams, or MLB’s 30 teams needs a selection method whose source range divides evenly by the league’s team count — 32 divides a single random byte’s 256 possible values perfectly, but 30 does not, leaving a naive byte-modulo implementation with a small, avoidable 0.39-percentage-point bias toward 16 of the 30 teams.
A worked example with numbers
A single random byte has 256 possible values, from 0 to 255. Selecting among the NFL’s 32 teams with `byte % 32` divides cleanly: 256 ÷ 32 = 8 exactly, so every team gets precisely 8 of the 256 possible byte values, an exactly equal 8/256 = 3.125% chance each, with zero bias. Selecting among the NBA’s or MLB’s 30 teams the same way does not divide evenly: 256 ÷ 30 = 8 remainder 16, so 16 of the 30 teams end up with 9 possible byte values each (a 9/256 ≈ 3.516% chance) while the other 14 teams get only 8 each (3.125%, the same share the NFL case gave every team). That gap — roughly 3.516% versus 3.125% — is small on any single pick, but it is a real, structural bias built into the method, not a rounding artifact that averages out.
How to set the rule before the result
The standard fix is rejection sampling: draw a random byte, and if its value falls in the range that would create the uneven leftover — here, the top 16 values from 240 to 255 — discard it and draw again, rather than reducing it with modulo. Discarding those 16 values out of 256 means about 6.25% of draws get thrown away and re-rolled, but every one of the 30 teams then has an exactly equal 8/240 = 3.3333...% chance, with no structural bias left at all. The same fix generalises directly to picking one item from any list whose length does not evenly divide the size of the underlying random source, which is most list lengths most of the time — 32 dividing 256 cleanly is closer to a special case than a rule.
Common mistakes that change the odds or the process
A common mistake is assuming a bias this small — 0.39 percentage points — cannot possibly matter, without checking against the actual number of picks the tool will make; run the biased method a million times and the 16 favoured teams collect roughly 3,910 more selections combined than the 14 disfavoured teams would receive under a truly uniform method, a gap that becomes clearly visible in aggregate even though it is invisible in any single pick. A second mistake is fixing the modulo bias by switching to a much larger random source, such as a 32-bit integer, without checking whether that actually solves the problem — 2³² divided by 30 still has a remainder, so the bias shrinks to about two parts in ten billion rather than disappearing, negligible for this use but not literally zero. A third mistake is assuming every professional league has the same team count as the one just checked — a different sport or a different country’s league can have a meaningfully different total that changes which method’s bias matters.
Where this method stops being appropriate
This bias-avoidance method only addresses selecting fairly among a fixed, correctly counted list of named teams; it says nothing about whether that list itself is accurate or current — a league can expand, contract, or relocate a franchise, and a hard-coded team list needs to be updated to reflect the current count, or the “fair” selection is fair only among an outdated roster. It also does not address weighting by any other factor, such as market size, recent performance, or personal preference; a uniform random pick treats every listed team as equally likely by design, a deliberate simplification appropriate for a genuinely arbitrary choice, not a ranking or recommendation.
How the random source fits into the rule
The current team counts used above — 32 NFL teams, 30 NBA teams, and 30 MLB teams — are documented on each league’s own team-directory page: NFL.com’s teams page, NBA.com’s teams page, and MLB.com’s teams page. MDN’s Math.random reference documents the underlying uniform random source most modulo-based selection code starts from before this kind of range-conversion bias is introduced or avoided.
Byte-modulo bias across a few common league sizes
| League | Teams | 256 mod teams | Favoured teams’ chance | Other teams’ chance |
|---|---|---|---|---|
| NFL | 32 | 0 (no bias) | 3.125% | 3.125% |
| NBA | 30 | 16 | 3.516% | 3.125% |
| MLB | 30 | 16 | 3.516% | 3.125% |
The “256 mod teams” column is the number of leftover byte values after dividing as evenly as possible; when it is zero, as with the NFL’s 32 teams, a plain modulo selection is already exactly fair, and no rejection step is needed at all.
A second case: picking fairly with a 32-bit source instead
Switching from a single byte (256 values) to a 32-bit integer (4,294,967,296 values) shrinks the same structural bias without eliminating it: 2³² divided by 30 leaves a remainder of 16 out of over four billion, giving 16 teams a share of about 33.33333336% and the other 14 a share of about 33.33333326% — a gap of roughly two parts in ten billion, far below anything a realistic number of picks could ever detect. For a casual “pick a team to follow” tool, a 32-bit source without rejection sampling is a reasonable practical compromise; for a use case where exact fairness must be provable rather than merely negligible, rejection sampling remains the only method with zero structural bias.
Why rejection sampling is worth building once, not recalculating each time
A tool built once with proper rejection sampling handles every future list length correctly without needing a fresh bias calculation each time a league realigns or a new sport is added — 31 teams, 29 teams, or 7 teams all get the same guaranteed-uniform treatment automatically. Relying instead on “the bias is small enough this time” requires re-checking that judgment call every time the underlying list size changes, exactly the kind of maintenance burden a single, correctly implemented rejection-sampling routine removes for good, regardless of the source width chosen.
The same method applies just as directly to a smaller population, such as picking fairly among the 32 teams in one conference split into two 16-team divisions, or among a single division’s 4 or 5 teams — the only input that changes is N, the count of eligible items, while the rejection-sampling logic itself stays identical. A tool that lets a user narrow the pool first, such as “pick only from teams in one conference,” needs the fairness check re-run against that narrower count rather than assuming whatever bias analysis applied to the full 32-team list still holds once the list has been filtered down to 16.