Random Number Generator

Using the Random Number Generator

1. Set the Min and Max inputs to define an inclusive range. Negative numbers and decimals are both accepted.
2. Choose how many numbers to generate with the Count input, from 1 up to 1000. The control is just a numeric field, so you can paste large counts rather than holding a button.
3. Toggle the option checkboxes: Allow duplicates permits repeats, Sort results orders the output ascending, and Integers only restricts to whole numbers rather than floats.
4. Press Generate. The result grid fills immediately; each number is its own cell so you can copy a single value with a click, or use the Copy All button for a comma-separated dump.
5. Regenerate as often as you want. The tool pulls fresh entropy each time, so consecutive runs will not repeat.

Which Random Source Is Used

The tool uses crypto.getRandomValues, the cryptographically secure interface exposed by the Web Crypto API on every modern browser. For integer output it asks for a Uint32Array, then maps each 32-bit value into the target range using rejection sampling to avoid modulo bias. For float output it calls getRandomValues on a Uint32Array and converts to a uniformly distributed float in [0, 1) by dividing by 2³², which preserves uniformity better than the common Math.random()-based shortcut.

The distinction matters. Math.random() in V8 uses an xorshift128+ PRNG seeded at tab creation; it is fine for casual games and UI shuffles but emits predictable sequences once a few outputs are known, and its uniformity over large ranges is weaker than a proper cryptographic source. crypto.getRandomValues routes to the operating system CSPRNG (on Linux, getrandom(2); on macOS, /dev/urandom; on Windows, BCryptGenRandom) and is suitable for token generation, sampling without predictability, and anything where an adversary might observe outputs. The entire generation runs client-side; nothing is sent to a server.

Real Tasks This Is Useful For

• Picking a raffle or giveaway winner from a numbered list of entries.
• Seeding a test fixture with reproducible-looking data that is actually unpredictable.
• Generating a short set of non-duplicate lottery numbers for a casual pool.
• Building a shuffled sample for QA - for example 20 order IDs out of a larger range to spot-check.
• Producing a random tick schedule for a load test that should not be on round intervals.
• Making up test salaries, ages, or prices for a UI mockup without leaking real data.

Common Pitfalls

• Modulo bias. Naive code that maps a 32-bit random value with value % range over-represents the lower end when range does not divide 2³² evenly. The tool rejects out-of-band draws instead, which is slower on paper but imperceptible in practice.
• Duplicates when you did not want them. Uncheck Allow duplicates. The tool will then error if your count exceeds the available distinct integers in the range.
• Float precision. Floats use IEEE 754 binary64, so not every decimal value in your range is representable. Two calls might land on the same nominal decimal by rounding.
• Range boundaries. Both Min and Max are inclusive. If you want half-open behaviour like most programming libraries (for example Python's range), subtract 1 from your Max.
• Sorting hides duplicates. With Sort results on and Allow duplicates on, identical values end up adjacent and are easy to miss at a glance; scan before interpreting.
• Very large counts (close to 1000) with unique-only mode and a small range can take a visible moment because the rejection-sampling loop has to avoid already-drawn values.

What "Random" Actually Means Here

A random number source has two properties that matter: uniformity (every value in the range is equally likely) and unpredictability (future outputs cannot be inferred from past ones, even with unlimited compute). Math.random() delivers the first but not the second; a CSPRNG delivers both. The NIST SP 800-90A and 800-90B documents define the standard for cryptographic DRBGs, and crypto.getRandomValues is specified against that standard by the W3C Web Cryptography API (TR 2017, last significant revision 2024). For dice, cards, and everyday shuffling the difference is invisible; for anything that could plausibly be attacked - session tokens, one-time passwords, game seeds where an adversary gains from prediction - the difference is critical.

Alternatives and Tradeoffs

Command-line alternatives include shuf -i 1-100 -n 10 for a shuffled sample (GNU coreutils), jot -r 10 1 100 on macOS and BSDs, Python's secrets.choice and random.sample, and openssl rand for raw bytes. For reproducible-with-a-seed generation you want numpy.random.default_rng(seed) or Julia's Random.MersenneTwister(seed); this tool deliberately does not expose a seed because seeding a CSPRNG defeats its purpose. Spreadsheets have RAND and RANDBETWEEN, both based on engine-specific PRNGs that should not be trusted for anything adversarial. Dedicated hardware sources (HRNGs) like Intel RDRAND or the ID Quantique quantum RNG are overkill for non-cryptographic applications but exist when you need a certified entropy source.