Why Math.random() Can Be the Wrong Choice for a Random Picker
Mapping bias occurs when code converts a source range into target choices so that some choices receive more source values than others.
A worked example with numbers
Imagine a picker with three labels, Red, Blue, and Green. A developer generates an integer from 0 through 9 and applies `% 3`. Remainder 0 occurs for 0, 3, 6, and 9: four values. Remainders 1 and 2 occur for only three values each. Red therefore has 40% probability if it receives remainder 0, while Blue and Green each have 30%. The fault is not that the values are “not random enough”; it is that ten source outcomes cannot be divided into three equal groups. Rejecting 9 before applying `% 3` leaves nine values and gives every label 3/9 = 1/3.
How to set the rule before the result
For a harmless display, `Math.random()` can generate temporary dice faces while a separate result function chooses the final value. For the choice itself, select an integer uniformly. The random list picker uses a bounded index; the weighted wheel instead maps a point on the explicit total weight. These are different mappings with different fairness statements. If a picker falls back from crypto on an older environment, disclose that it remains a convenience tool rather than silently claiming cryptographic strength.
Common mistakes that change the odds or the process
Do not use `Math.round(Math.random() * (max - min)) + min` for an inclusive integer range. The two endpoints correspond to half-width intervals, so they are less likely than interior integers. Do not multiply a random number by a list length until the list has been cleaned: an empty line or accidental duplicate changes the number of targets. Do not use a random picker for passwords, reset links, gambling outcomes, confidential identifiers, or any selection where an attacker could benefit from predicting the result.
Where this method stops being appropriate
The limitation is about threat model, not embarrassment. A lunch picker with five dinner options has no secret to protect; an attacker who predicts Pasta gains nothing. A session token or password has a secret to protect; a predictable source can expose an account. For consequential allocation, problems also remain even with Web Crypto: a secure draw does not authenticate participants, prove a list was complete, or provide appeal rights. Choose a documented external procedure when those controls are required.
How the random source fits into the rule
MDN’s Math.random reference states that Math.random returns a pseudo-random float from 0 inclusive to 1 exclusive and should not be used for cryptography. MDN’s Crypto.getRandomValues reference documents the browser alternative for strong random integer values. DiceDecide rejects excess 32-bit values before taking a remainder in its index selectors, which is why a 3-item list can be divided into three equal accepted classes instead of inheriting a source-range remainder.
Separate source quality from range conversion
Two independent design decisions determine a picker. Source quality asks whether someone could predict the next raw value. Range conversion asks whether the raw values reach target choices equally. Replacing a biased conversion with Web Crypto does not repair a mapping that gives remainder zero four source values and other remainders three. Likewise, a mathematically even conversion from Math.random does not make a password safe. Review both layers whenever the result has more consequence than a visual effect.
A reliable integer pattern is: request an unsigned value, calculate the largest allowed source interval that is divisible by the target count, reject a value outside that interval, then take the remainder. The rare rejection is not a retry after an inconvenient answer; it happens before an outcome label exists. Keep that distinction clear in code reviews. The choice of source should be explicit too, so a future developer does not treat an animation helper as the security mechanism for a token or an access decision.