Random number generator

What is a Random Number Generator?

A random number generator produces unpredictable numbers within a range you specify — integers between a minimum and maximum, decimals, or batches of numbers for sampling, testing, and decision-making. True randomness is surprisingly hard for computers: the deterministic machines we use cannot be random by themselves, so they rely on either physical entropy sources (timing jitter, thermal noise, operating-system entropy pools) or carefully designed pseudorandom algorithms seeded from such sources. Our tool uses the platform's cryptographically secure random source, so every number it returns is unpredictable in the strongest practical sense.

The distinction that matters most is statistical randomness vs. cryptographic randomness. A statistical PRNG (like the Mersenne Twister behind many languages' default random()) produces numbers that look random and pass statistical tests — fine for simulations, games, and shuffling playlists. But its output is predictable if an attacker learns enough of it, which makes it dangerous for security uses: tokens, salts, password generation, lottery draws, or anything where money or access depends on unpredictability. A CSPRNG (cryptographically secure pseudorandom number generator) is designed so that observing past output gives no usable information about future output. Our generator uses a CSPRNG, which means it is safe for both casual and security-sensitive uses — one tool, no wrong choice.

Random numbers quietly power an enormous range of everyday tasks. Developers generate them for test data, randomized load tests, feature-flag rollouts (show the new UI to 10% of users), and A/B test bucketing. Data scientists sample datasets and seed Monte Carlo simulations. Teachers and presenters pick raffle winners and assign random groups. Gamers roll dice and generate loot. Statisticians draw random samples for surveys. And security engineers generate salts, nonces, and one-time codes. The common thread: whenever a human would introduce bias — consciously or not — a proper random source removes it.

Two honest caveats. First, "random between 1 and 10" from a good generator gives each number equal probability, but humans are terrible at recognizing true randomness: real random sequences contain streaks and repeats (the same number twice in a row is normal, not broken). Second, if you need unique random numbers (a raffle with no duplicate winners, a shuffled deck), that is sampling without replacement — a different operation from independent draws, and our tool supports both modes so you get exactly the statistics you intend.

Our free random number generator produces integers or decimals in any range you set, single values or large batches, with optional uniqueness and sorting — all from a cryptographically secure source. Your requests are processed instantly and never stored. It pairs with our UUID v4 generator for unique identifiers, our password generator for secrets, and our JSON validator when random data goes into test payloads.

How to Use the Random Number Generator

Generating random numbers takes seconds:

1. Set your range. Enter the minimum and maximum values. For a classic die roll use 1–6; for a percentage use 1–100; for a one-time code use 100000–999999. Negative ranges and large ranges are fine.
2. Choose integers or decimals. Pick whole numbers for dice, draws, and IDs, or decimal numbers (with configurable precision) for simulations, measurements, and statistical work.
3. Set the quantity. Generate a single number for a quick decision, or a batch of hundreds/thousands for test data, sampling, or analysis. Each value in a batch is independently random.
4. Decide on uniqueness. For draws where repeats are not allowed (raffle winners, lottery-style picks, shuffled assignments), enable "unique numbers" — the tool samples without replacement. Keep this off when each draw should be independent (dice rolls, repeated experiments).
5. Generate. Click the generate button. Numbers come from the platform's cryptographically secure random source, uniformly distributed across your range — every value equally likely, no patterns, no bias.
6. Copy or export. Copy the results as a list, or sort them if you need ordered output for analysis. Building a test suite? Combine with UUIDs for identifiers and validate the assembled fixtures with our JSON validator.

Key Features of the Random Number Generator

Cryptographically secure source. Every number comes from the operating system's CSPRNG (the same class of source used for TLS keys), not a predictable Math.random()-style generator — safe for tokens, draws, and anything adversarial.

Any integer range. From 1–6 dice to 1–1,000,000 raffles to negative ranges for simulations — set any minimum and maximum, with uniform distribution guaranteed across the interval.

Decimal support. Generate floating-point values with configurable decimal places for scientific, financial-modeling, and simulation use cases where integers will not do.

Bulk generation. Produce thousands of values in one click for test datasets, Monte Carlo runs, and statistical sampling — each independently random.

Unique mode (no repeats). Sample without replacement for raffles, random assignments, and shuffles, with validation that your range is large enough for the requested count.

Sorting and formatting options. Output raw in generation order or sorted ascending/descending, as comma- or newline-separated lists ready to paste into spreadsheets, code, or documents.

Private by design. No signup. Your generations are processed instantly and never stored or logged.

Random Number Generator Use Cases

Developers

The problem: You need realistic test data — a thousand users with plausible ages, order totals, and timestamps — but hand-writing fixtures produces suspiciously uniform data that never exercises edge cases, and your language's default random() is predictable enough to be a liability in security-adjacent code.

How this tool helps: Generate bulk random values in the exact ranges your schema needs: ages 18–90, totals 5.00–500.00, quantities 1–50. The CSPRNG source means the same approach safely generates salts, nonces, and verification codes in your actual application logic. Assemble the values into fixtures and run them through our JSON validator before loading them into your test database.

Teachers, organizers, and presenters

The problem: You are running a giveaway, assigning presentation order, splitting a class into random groups, or picking a raffle winner — and doing it by "picking" yourself invites (accurate or not) accusations of favoritism. "The organizer chose" never feels fair.

How this tool helps: Number the entries 1–N, generate unique random numbers in that range with the tool, and let the numbers decide — on screen, in front of everyone. The unbiased, auditable process defuses favoritism complaints completely. For group assignment, generate a shuffled unique sequence and deal participants out in order; for winners, generate one number per prize.

Students learning statistics and probability

The problem: Probability theory says a fair die shows each face 1/6 of the time and that streaks are normal — but rolling a physical die 600 times to verify it is nobody's idea of homework, and spreadsheet RAND() functions feel like black boxes.

How this tool helps: Generate 1,000 integers in 1–6 and tally the frequencies: watch them converge toward uniformity as the sample grows — the law of large numbers, demonstrated live. Then look at the sequence itself and find the streaks (three 4s in a row will appear); this viscerally teaches the clustering illusion, the reason humans distrust true randomness. It is the fastest possible lab for the intuitions probability courses try to build.

Generating Random Numbers in Code: The Right Way

Every language ships a random function, and in almost every language the default one is wrong for security-sensitive work. Here is how to do it correctly across the stack.

Python. The random module (Mersenne Twister) is fine for simulations, shuffling, and sampling — random.randint(1, 100), random.sample(population, k) for unique picks, random.shuffle() for in-place shuffling. For anything security-adjacent (tokens, salts, OTPs, secrets), switch to the secrets module: secrets.randbelow(100), secrets.token_hex(16), secrets.choice(alphabet). The rule is absolute: random for models, secrets for security — never mix them up.

JavaScript. Math.random() is a non-crypto PRNG: fine for games, animations, and A/B bucketing, dangerous for tokens. For secure values use crypto.getRandomValues(new Uint32Array(1))[0] in browsers or crypto.randomInt(min, max) in Node.js — the latter even handles range mapping without modulo bias. A subtle classic bug: Math.floor(Math.random() * n) is uniform, but Math.round(Math.random() * n) is not (the endpoints get half the probability) — always use floor for integer ranges.

Java. java.util.Random is predictable (48-bit seed, reconstructible from outputs); SecureRandom is the CSPRNG. Use SecureRandom.nextInt(bound) for unbiased bounded integers — it avoids the modulo bias that naive nextInt() % n introduces when the range is not a power of two. Spring and Jakarta EE code handling sessions or tokens should exclusively use SecureRandom.

PHP. rand() and mt_rand() are not cryptographically secure; random_int($min, $max) and random_bytes($n) are — and random_int is unbiased for any range. Any PHP code generating password-reset tokens, CSRF tokens, or API keys with mt_rand() has a vulnerability; the fix is a drop-in replacement.

Modulo bias, explained. Mapping a large random value into a smaller range with % n is biased unless the source range is an exact multiple of n: some outcomes get one extra source value. With a 32-bit source and small n the bias is negligible, but with small sources (a byte mapped into 1–100) it is measurable — and in lotteries or shuffles, measurable bias is a fairness bug. Use rejection sampling (regenerate values that fall in the partial final bucket) or your platform's unbiased bounded function (random_int, SecureRandom.nextInt(bound), crypto.randomInt).

Seeding and reproducibility. Simulations often need reproducible randomness: seed the PRNG explicitly (random.seed(42)) so results are identical across runs — essential for debugging and peer review. But never seed a CSPRNG manually in production, and never reuse seeds across security contexts. Reproducibility is a feature for science and a vulnerability for security; keep the two worlds separate.

The one-line summary: know which of your random calls need unpredictability, and give those — and only those — the CSPRNG. Everything else can stay fast and simple.

Fairness Checklist for Giveaways and Draws

Running a public draw? Unbiased numbers are only half of fairness — the process must also be seen to be fair. Use this checklist. Publish the rules first: eligibility, entry numbering, how winners are selected, and how many prizes — before the draw, not after. Number entries transparently: assign sequential numbers in a verifiable order (signup order, alphabetical) and share the list. Draw live or record it: generate the winning numbers on screen during a livestream, or record the screen showing the tool's settings (range, unique mode) and the moment of generation. Use unique mode so no entry wins twice unless the rules allow it, and set the range to exactly the entry count — no gaps, no padding. Document everything: screenshot the settings and results with timestamps, and keep them until prizes are delivered. Handle edge cases in the rules: what happens if a winner is ineligible or unresponsive (redraw from remaining entries, with the same process). A draw that follows this checklist survives scrutiny; one that does not invites exactly the accusations of favoritism the tool exists to prevent.

Frequently Asked Questions

Are the numbers truly random?

They are cryptographically secure pseudorandom numbers from the operating system's entropy-based CSPRNG — unpredictable in every practical sense, and suitable even for security-sensitive uses like tokens and draws. Strictly speaking, "true" randomness requires a hardware physical process (atmospheric noise, quantum effects), but a well-seeded CSPRNG is computationally indistinguishable from true randomness: no observer can predict the next value from previous ones. For every use case this tool targets, the distinction has no practical consequence.

What is the difference between a CSPRNG and Math.random()?

Math.random() and similar default generators (Mersenne Twister in many languages) are designed for speed and statistical uniformity, not unpredictability: their internal state can be reconstructed from observed outputs, letting an attacker predict future values. A CSPRNG is designed so that prediction is computationally infeasible even with full knowledge of past outputs. Rule: default PRNGs for simulations and games where prediction does not matter; CSPRNGs for anything involving security, money, fairness, or adversarial observers. Our tool uses a CSPRNG, so it is safe for both categories.

How do I generate random numbers without duplicates?

Use the "unique numbers" (sampling without replacement) mode: the tool draws from your range and never repeats a value, like pulling names from a hat. This is the correct mode for raffle winners, lottery picks, shuffled assignments, and random sampling of a population. Note the mathematical constraint: you cannot draw more unique numbers than the range contains (no 10 unique numbers from 1–6). For independent repeated draws where repeats are fine — dice rolls, repeated experiments — leave unique mode off.

Why do random sequences contain repeats and streaks?

Because that is what randomness actually looks like. In 20 rolls of a fair die, the chance of at least one back-to-back repeat is about 97% — repeats are the norm, not a defect. Humans expect randomness to "look" evenly spread (alternating, balanced), but that expectation describes a shuffled, balanced sequence, not independent random draws. This mismatch is the clustering illusion, and it is why people accuse fair random processes of being rigged. If your generated sequence has streaks, the generator is working correctly.

Can I use this for a lottery, raffle, or giveaway?

Yes — unbiased random selection is exactly what the tool is for. Number your entries, generate unique random numbers in that range, and document the process (screenshot the settings and results) so winners and observers can see it was fair. One legal note: actual lotteries and gambling operations are regulated in most jurisdictions and require certified hardware RNGs and oversight — this tool is appropriate for informal raffles, classroom draws, marketing giveaways, and similar non-regulated selections, not for operating a licensed lottery.

How do I generate a random password with this tool?

You should not — use a dedicated tool instead. Mapping random numbers to characters by hand is error-prone and usually produces weaker passwords than intended (people shrink the character set or shorten the length for convenience). Our password generator is built for exactly this: it draws from the full printable character set with a CSPRNG and gets the entropy math right. Use the random number generator for numbers; use the password generator for secrets.

What range and settings should I use for dice?

A standard die is integers from 1 to 6, single draw. Two dice: either generate 2 numbers in 1–6 and add them, or generate 1 number in 2–12 — but note these are not equivalent distributions: the sum of two dice is bell-shaped (7 is six times likelier than 2), while a single 2–12 draw is uniform. For percentile dice use 1–100; for a d20 use 1–20. Tabletop gamers: generate each die separately and sum them to preserve the correct probability curves your game was balanced around.

Is it safe to use generated numbers as API keys or tokens?

Numbers from this tool's CSPRNG are unpredictable enough to serve as nonces, request IDs, and one-time numeric codes (e.g. 6-digit verification codes). For API keys and session tokens, prefer longer alphanumeric secrets — our password generator produces those — because a 6-digit code has only a million possibilities and must be paired with rate limiting and expiry. The general principle: the secret's entropy must exceed what an attacker can guess within its lifetime, given your throttling.