Random Number & Data Generators

Pure number generation

The random number generator is the broadest tool in this category — any minimum, any maximum, one value or a whole batch, all drawn with the same rejection-sampling fairness guarantee as everything else here. Batch requests get an extra safeguard worth calling out: rather than generating candidates and throwing away any that happen to repeat, which would slow down and get messier as fewer unused numbers remain, it pulls each value directly out of a shrinking pool of what's left, so there's no repeat to filter out in the first place because there was never a chance for one to occur.

The number wheel takes that same fair-range idea and adds the spinner wheel's arc-proportion visual mechanic on top, auto-populating a spinning wheel with your chosen number range instead of custom text. Its real practical addition over the plain number generator is an optional 'remove after call' mode built for bingo-style live number calling, where numbers already called shouldn't come up again.

Security codes: passwords and PINs

The random password generator builds a password character by character from whichever character types you enable -- uppercase, lowercase, digits, symbols -- each drawn independently from that pool via rejection sampling. The real security metric here is entropy: with a roughly 94-character pool (all types on), each character contributes about 6.5 bits, so a 16-character password lands around 104 bits of entropy, far beyond what any realistic brute-force attempt could crack.

The random PIN generator is the digits-only sibling: each digit is drawn from just 10 possible values (0 through 9), contributing only about 3.32 bits of entropy each -- meaningfully weaker per character than a mixed password, which is exactly why a 4-digit PIN (about 13 bits total) is so much weaker than even a short mixed password, and why 6- or 8-digit PINs exist for anywhere that needs stronger numeric-only security.

Calendar and clock: dates and times

The random date generator and random time generator both solve the same category of problem -- picking a fair point within a calendar or clock range -- using the same underlying trick: convert the range into a flat integer (days since a reference point, or minutes/seconds since midnight), draw a fair integer within that flat range via rejection sampling, then convert back into a readable date or time.

That flat-integer conversion matters because randomizing a date's month and day separately (or a time's hour and minute separately) would introduce bias -- not every month has the same number of days, so picking month and day independently would under-represent dates like the 31st and over-represent February relative to its real share of the year. Working in day-count or minute-count space avoids that specific problem entirely, giving every real calendar day (leap days included) or every real minute in the window a genuinely equal chance.

Choosing between the six number tools

Reach for the random number generator whenever the range itself is the point -- a raffle needs a ticket number, a stats lesson needs a live demonstration, a board game is missing whatever oddly-sized die a rule calls for. It's also the pick when you need several different numbers at once rather than just one. Want that same fair range wrapped in a visual spin and an auto-removal mode built for calling numbers out loud (bingo night, a live raffle draw)? The number wheel layers that presentation on top without changing the underlying fairness at all.

For anything that needs to double as a real credential, the choice comes down to what the destination accepts: a mixed-character password if letters and symbols are allowed (it's meaningfully stronger per character), or a numeric-only PIN if the destination specifically restricts to digits. For calendar or clock values, the date and time generators are purpose-built and shouldn't be replicated with the plain number generator, since naively randomizing month-and-day or hour-and-minute separately introduces the exact bias those two tools are built to avoid.

Why crypto.getRandomValues instead of Math.random()

JavaScript's built-in Math.random() is a pseudo-random number generator -- fast, deterministic under the hood, and never designed with unpredictability as a goal. Its output can, in principle, be predicted or reverse-engineered from enough prior outputs, because it's built from a mathematical formula optimized for speed and statistical distribution, not for resisting prediction. That's a fine tradeoff for a lot of casual uses, but it's the wrong tool anywhere fairness or security actually matters -- a password generator built on Math.random() would be genuinely weaker than one built on a cryptographic source.

crypto.getRandomValues instead pulls from the operating system's own cryptographic random generator, the same kind of source behind encryption-key generation, purpose-built so that watching past results tells you nothing about what's coming next. That's why every tool in this category, and everywhere else on the site, is built on it rather than on Math.random() -- a tool that claims to be fair while quietly running on a source that was never designed to resist prediction isn't really keeping that promise.

A note on precision and rounding

No tool in this category silently rounds or truncates a result in a way that would skew fairness -- the number generator and number wheel return exact whole numbers within your set range, the password and PIN generators return exact character-by-character draws with no rounding concept to apply, and the date and time generators resolve to whichever precision you choose (a full calendar day, or a minute versus a second) without ever collapsing multiple possible results into one displayed value. The decimal generator does round, by necessity, and states on its own page exactly what that costs the two endpoints of your range. That matters because rounding is itself a form of weighting -- if a tool quietly grouped several distinct underlying outcomes into one displayed result, some displayed results would end up more likely than others even if the underlying draw was fair.

Continuous values, and what rounding costs

The decimal generator is the exception to this category's whole-numbers pattern, and its fairness question is a different one. The draw itself is continuous and uniform across your interval; what introduces a wrinkle is rounding the result to a fixed number of places for display.

Rounding buckets a continuous distribution, and the two endpoints get half-width buckets because there is nothing beyond the interval to round inwards from. Asking for two decimal places between zero and one gives 101 possible outputs, of which 99 have probability 0.01 and the two endpoints have about 0.005 — so 0.00 and 1.00 come up about half as often as any interior value.

That is a genuinely different problem from the modulo bias the rest of this category corrects. Modulo bias comes from mapping 256 byte values onto a range that does not divide evenly, and rejection sampling eliminates it entirely. Endpoint deficit is inherent in rounding a continuous quantity into buckets, and the honest response is to state it rather than to claim it away.

Where every displayed value must be exactly equally likely, the answer is to draw integers with the number generator and place the decimal point yourself. An integer draw from zero to a hundred divided by a hundred gives 101 genuinely equiprobable values, because the draw was discrete from the start.

Drawing without replacement: bingo and lottery sets

Both tools remove drawn values from the pool, which makes a repeat structurally impossible rather than prevented by a check performed afterwards. That is a stronger guarantee, because there is no check to get wrong — the number is simply no longer in the bag.

The visible consequence is that the odds rise as the draw proceeds. The first bingo call of a seventy-five ball game is one in seventy-five and the sixtieth is one in sixteen, which is why the tail of a long game speeds up noticeably even though nothing about the tool has changed.

The bingo caller's real contribution is not the draw at all. Nobody has ever seriously disputed whether a bingo number was random; every dispute is about whether a number was called, which makes a permanently visible called-board worth more than any property of the randomness. The card checker resolves a claim in seconds by comparing pasted numbers against the called set.

The lottery generator computes the exact combination count alongside every line, and that number is more informative than the line. Six from forty-nine is 13,983,816 combinations, every one exactly as likely as every other — which is precisely why no generator can improve anyone's chance of winning anything, and the page says so with a visible disclaimer rather than in small print.

Splits, seeds and walks

The percentage allocator splits a whole into parts that sum exactly to the total, and it does so by dropping cut points into an interval and taking the gaps. The obvious alternative — draw a number for each part and normalise — is not uniform: sums of independent draws concentrate, so every share gets pulled toward one over n and a genuinely lopsided split becomes nearly impossible. Sorted cut points have no such pull, which is why a four-way split here will regularly produce a 3 next to a 60.

The seed generator is the only tool on this site that does not use crypto.getRandomValues, and that is deliberate rather than an oversight. It hashes a readable seed phrase into a 32-bit integer and runs a pseudo-random generator from it, so the same seed produces the same result on any device at any time. Reproducibility and unpredictability are mutually exclusive, and a draw somebody has to be able to check afterwards needs the first one.

That makes it the right tool for a published giveaway and completely wrong for anything that must be unknowable in advance — anyone holding the seed knows every value it will produce. The stronger protocol, publishing a hash of the seed before the draw and the seed itself afterwards, additionally proves the seed was not chosen after seeing who entered.

The random walk generator produces a picture rather than a number. Two hundred fair steps typically finish about fourteen away from the origin, because typical distance grows as the square root of the step count while the expected position stays exactly zero — and the drawn path spends long stretches entirely on one side of the line. That visual is the most persuasive available answer to somebody convinced a picker is rigged.

Frequently asked questions