What random means on a computer
Random describes uncertainty about which eligible outcome will be returned; it does not promise that a short run will look evenly spaced. A fair six-outcome process gives every face probability 1/6 on each independent draw, yet 2, 2, 5, 2 is possible. Repeats and clusters are normal. Uniformity is a statement about the probability model and long-run frequencies, not a rule forcing every small batch to contain each result once.
Most software uses a deterministic pseudorandom number generator, or PRNG. Given the same internal state, a PRNG produces the same sequence. Its usefulness depends on how that state is initialized and whether an observer can predict it. A cryptographically secure PRNG, or CSPRNG, is designed so that outputs remain difficult to predict even when an attacker knows the algorithm. That stronger property matters for security, while ordinary simulations may use reproducible PRNG seeds deliberately.
Browser Web Crypto and the NumUtility source
The Web Crypto API exposes crypto.getRandomValues(), which fills integer typed arrays with cryptographically strong random values. Browsers normally implement it with a CSPRNG seeded from operating-system entropy. The standard does not promise a particular algorithm or a minimum information-theoretic entropy for every device. It also advises using purpose-built key-generation operations for cryptographic keys rather than treating arbitrary random bytes as a complete key-management process.
NumUtility's Random Number Generator requests one unsigned 32-bit value from Web Crypto when that API exists. If Web Crypto is unavailable, the current component falls back to Math.random(). That fallback is not a cryptographic source. The tool is therefore for ordinary choices and demonstrations, not security tokens, encryption keys, regulated lotteries, certified drawings, or scientific sampling that requires a documented and auditable design.
Inclusive integer ranges
An inclusive range contains both endpoints. The number of possible integers is maximum − minimum + 1. Input: minimum 1 and maximum 6. Formula: 6 − 1 + 1. Calculation: 6 outcomes. Result: {1, 2, 3, 4, 5, 6}. Interpretation: each endpoint is eligible, so a correct uniform mapping gives each integer probability 1/6.
Input: minimum −3 and maximum 3. Formula: 3 − (−3) + 1. Calculation: 7 outcomes. Result: {−3, −2, −1, 0, 1, 2, 3}. Interpretation: crossing zero does not change the counting rule. If minimum equals maximum, the range contains one outcome and the only valid result is that endpoint. If the rounded lower endpoint exceeds the rounded upper endpoint, no integer can be generated.
Decimals, large ranges, and validation
The current interface converts both fields to JavaScript numbers, rounds the minimum upward with Math.ceil, and rounds the maximum downward with Math.floor. A request from 1.2 to 4.9 therefore uses integers 2 through 4. Negative decimals follow the same rule: −3.8 through −1.2 becomes −3 through −2. Non-numeric values cause the range check to fail indirectly and display the generic valid-range message. The page should be understood as an integer generator, not a decimal generator.
A 32-bit Web Crypto sample has 2^32 possible states. The current code does not explicitly reject integer ranges larger than that state space, unsafe JavaScript integers, Infinity, or precision-collapsed endpoints. Results for extreme inputs can therefore be misleading or unreachable. Use ordinary safe-integer ranges only. This boundary is an implementation limit, not a mathematical limit on random integers.
Why simple modulo mapping can be biased
Modulo bias occurs when mapping computes source value mod range size and the source-state count is not divisible by the number of outcomes. Input: an imagined source with states 0 through 7 mapped to three outcomes A, B, C. Formula: state mod 3. Calculation: A receives states 0, 3, 6; B receives 1, 4, 7; C receives 2, 5. Result: probabilities 3/8, 3/8, and 2/8. Interpretation: A and B are more likely because eight states cannot be divided evenly among three outcomes.
The current Random Number Generator applies a 32-bit value modulo the requested range size directly, so it has this small modulo-bias defect whenever the size does not divide 2^32. Using a strong source does not fix a biased mapping. For a 1–6 range, four of the six residues receive one additional 32-bit source state. The difference is tiny for casual use but contradicts a strict claim of perfect uniformity.
How rejection sampling removes surplus states
Rejection sampling discards the unmatched top portion of the source space before applying modulo. Input: the same eight states and three outcomes. Formula: usable limit = floor(8 ÷ 3) × 3. Calculation: the limit is 6, so states 6 and 7 are rejected; states 0–5 remain. Result: each residue receives exactly two states. Interpretation: retrying after rejected states restores equal probability without inventing a preference.
NumUtility's Random Number Picker and Random Password Generator use this limit-and-retry technique in their shared random-index helper. The range generator currently does not. Rejection must happen before modulo, and retries must draw from the same appropriate source. Merely regenerating because a displayed answer looks repetitive would introduce human selection bias and destroy the stated procedure.
What the generator can and cannot establish
Use the Random Number Generator when every integer in one continuous, ordinary-sized min–max range is eligible and you need one informal result. Use the Random Number Picker when eligible values are nonconsecutive or when several distinct values must be selected without replacement. The fair-selection guide addresses eligibility, frozen lists, invalid winners, and records; the sampling guide explains changing probabilities after removal. Those procedural questions are separate from the source algorithm.
Do not interpret a result as proof that an overall process was fair. The tool does not verify the population, detect duplicate people, preserve an audit log, certify browser entropy, or meet a regulator's rules. It is not suitable for regulated lotteries, security keys, recovery seeds, or scientific work requiring certified randomization. Short sequences may repeat or cluster even after the mapping defect is corrected; random does not mean evenly distributed within every small sample.
Testing randomness claims carefully
A useful implementation review separates source, mapping, and procedure. First confirm which API supplies raw values and what happens when it is missing. Next inspect how raw states are converted to the requested outcome count, including ranges that do not divide the source space. Finally check input rounding, endpoint inclusion, one-outcome ranges, negative endpoints, unsafe numbers, and error messages. Passing a few visually varied draws proves none of these properties.
Frequency experiments can reveal large defects but cannot certify a generator from a small sample. For example, generating 600 die results does not require exactly 100 appearances of each face; natural variation is expected. A statistical test reports evidence under assumptions rather than proving future unpredictability. Code inspection exposes the current direct-modulo mapping deterministically, while the eight-state example explains why it is biased without depending on a lucky or unlucky run.
For a manual functional check, use 5 to 5 and confirm that every result is 5; use −3 to 3 and confirm both signs and zero are reachable; use 1.2 to 4.9 and confirm results stay within 2–4; and reverse the bounds to confirm no number is shown. These checks validate interface rules, not cryptographic strength. A corrected implementation would also test rejection behavior with a controllable source and would fail safely rather than changing to a weaker source when Web Crypto is unavailable.