A choice starts with a sample space
A random outcome is only meaningful after the eligible possibilities have been stated. An equal draw from five distinct names gives each name probability P(name) = 1/5. That equation is a property of the entry list, not of a button or animation. If Maya is entered twice while four other people appear once, there are six tickets: Maya has P(Maya) = 2/6 and each other person has 1/6. Calling that an equal five-person draw would describe the people but not the experiment actually run.
The same distinction matters when choices look similar. Two labels may represent one person, a withdrawn participant may remain in a list, or an item may be eligible only on particular dates. A browser cannot infer those facts. Before a turn order, a prize, or a task is assigned, agree on the entries, whether repeated entries are intentional, and whether every entry can accept the outcome. The result can be random without being fair to the people affected if the initial roster is wrong.
A bounded number needs more than a remainder
Random bytes do not automatically make every requested range even. A byte has 256 possible values. For a six-sided result, 256 divided by 6 leaves remainder 4: values 0 through 251 make 42 complete sets of six, while 252 through 255 are an incomplete tail. DiceDecide can reject that tail, take an accepted value modulo 6, and then add one. Each face has exactly 42 source values, so P(face) = 42/252 = 1/6.
Using every byte modulo 6 would quietly favour four faces: remainders 0 through 3 would each receive 43 source values and remainders 4 and 5 only 42. The numerical difference is small, but it is a real bias produced by the conversion, not by chance. The general rule for an unsigned 32-bit value and range size n is to accept values below floor(232 / n) × n. The accepted interval contains a whole number of n-sized groups, which is why every index receives the same count.
What the browser contributes—and does not certify
Where available, the code asks the browser for integer values through crypto.getRandomValues(), the Web Cryptography API method for filling typed arrays with random values. Browser implementations generally use a cryptographically strong pseudorandom generator rather than a physical coin toss; the Web Crypto specification does not promise a particular entropy source or a minimum amount of entropy. That is a useful source for an ordinary browser randomizer, not a certificate that a particular draw was independently witnessed.
A fallback based on Math.random can keep a casual game usable on an unusual browser, but it is not a substitute for cryptographic randomness. Neither source makes a result an audit record. The page does not verify identity, freeze a roster, collect signatures, timestamp consent, or preserve an immutable transcript. Those missing steps matter far more than the generator when a process must be contested later.
Worked example: a weighted equipment draw
Consider a game night with three equipment bundles. The organiser gives the starter bundle weight 5, the advanced bundle weight 3, and the challenge bundle weight 2. The total is W = 5 + 3 + 2 = 10. A random position on the interval from 1 to 10 maps positions 1–5 to starter, 6–8 to advanced, and 9–10 to challenge. The resulting probabilities are 5/10 = 50%, 3/10 = 30%, and 2/10 = 20%.
Suppose the first draw lands on position 10 and selects the challenge bundle. That does not show the method failed: a 20% event is expected to occur sometimes. Over ten independent redraws, the expected counts are five, three, and two, but expected counts are averages over many comparable experiments, not a schedule for one block of ten. A run could easily produce four challenge bundles or none. If the goal is to allocate one of each bundle, a weighted draw is the wrong model; prepare the physical set of available bundles and select without replacement.
Replacement changes the mathematics
In a draw with replacement, the original probabilities reset after every outcome. With a fair coin, five heads in a row have probability (1/2)5 = 1/32. After four heads, the next toss is still 1/2 heads if the tosses are independent; previous results do not create a balancing force. Reading a short streak as proof that tails is “due” is the gambler’s fallacy.
A shuffle is a different object. Six labelled cards have 6! = 720 possible complete orders. If one card is placed first and not put back, only five cards remain for the next position. A winner list, a seating order, and a deck deal need this no-replacement rule because a selected position cannot be selected again. Confusing the two models causes practical errors: repeated winners in a prize draw usually mean the process sampled with replacement when the organiser intended a shuffled list.
Weights are rules, not evidence
A visible weight describes how often an option should be available before the draw; it does not establish that the weight is deserved. A 4:1 hiring short-list, a 10:1 raffle entry ratio, or a priority score used to distribute scarce assistance introduces a policy choice before any random number is generated. The formula P(option) = weight / sum of positive weights is exact only after the values and eligibility rules have been approved. Changing a label, adding a duplicate, or altering a weight after seeing an unfavourable result changes the experiment.
For a low-stakes allocation, write down the entries and weights, show them to the group, run once, and preserve the displayed result if anyone needs to check it. If an error is found before the draw, correct the list and begin again openly. If it is found after the draw, do not quietly rerun until a preferred answer appears; decide with the affected people whether the original result stands or the process is void. That procedure is social accountability, not something a randomizer can supply by itself.
Where browser randomization ends
These tools suit games, classroom demonstrations, informal tie breaks, and other cases where participants can inspect and accept the rule. They are not an election system, a regulated raffle platform, a gambling service, a security-secret generator, or a decision-maker for medical, legal, financial, employment, educational, safety, or eligibility questions. Such settings may require a governing rule, verified participants, accessibility safeguards, records, appeal rights, and an authorised human decision.
Entries and results are calculated in the browser; the tool does not need an account to make the selection. Advertising and analytics are covered by the privacy policy. To report a reproducible fault, send [email protected] the page address, browser, exact inputs, and the observed result. Do not send passwords, private lists, or sensitive personal information. A report that preserves the inputs makes it possible to distinguish a defect in the calculation from a disagreement about the rule chosen before it.