Generators

Every other category on this site transforms something you already have. These tools are the opposite: you arrive with nothing but a few settings and leave with a result that did not exist before. That difference is not cosmetic. It changes what can go wrong, what you should check, and — for three of the four tools here — it makes the quality of the randomness underneath the only thing that actually matters.

Three kinds of random, and which one you need

The word "random" covers three quite different things, and picking the wrong one is the most common mistake in this whole category. At the bottom is a plain pseudorandom generator: a formula that produces a stream of numbers which pass statistical tests but follow deterministically from an internal state. Math.random in your browser is one of these — xorshift128+ in Chrome and Edge. From a short run of its outputs, the internal state can be recovered and every future value computed.

Above that is a cryptographically secure pseudorandom generator, seeded and continuously reseeded by your operating system from hardware entropy: timing jitter, interrupt patterns, and on most current processors a dedicated instruction that samples thermal noise. This is what crypto.getRandomValues gives you, and it is what every tool on this page uses. It is not predictable from its outputs, and it has no seed you can inspect — because a seed you could inspect would be a seed somebody else could guess.

At the top is a hardware source read directly, which matters for generating long-term cryptographic keys and essentially nowhere else. For deciding who goes first, picking a raffle winner, or producing a password you will store in a manager, the middle tier is not a compromise — it is the correct answer, and the gap between it and the bottom tier is where all the real risk lives.

Modulo bias: the shared defect of almost every online generator

A random source hands you a value from a fixed pool. To turn that into "a number from one to six" or "a character from this set", the pool has to be folded onto a smaller number of outcomes. The pool size is essentially never an exact multiple of the number of outcomes, so when you fold it, the first few outcomes get one extra slot each and come up slightly more often. That is modulo bias, and the standard one-line idiom — Math.floor(Math.random() * n) — has it.

The size of the effect depends on how large the range is relative to the pool. Rolling a die, it is far below anything anyone could notice. For wide ranges it becomes measurable, and the winners are always the low values in your range. Either way it is a defect that is easy to remove and nearly always left in.

The fix is rejection sampling: before folding, compute the largest value that divides evenly by the number of outcomes, throw away anything at or above that boundary, and draw again. The discarded region is tiny and what remains partitions exactly, so every outcome becomes exactly equally likely rather than approximately. Every random draw on this site works this way, and the number generator shows you a live distribution table so the claim is something you can check rather than something you have to accept.

Why a generator on a server is the wrong shape

For the random tools, the argument is short. crypto.getRandomValues reads your own machine’s entropy pool. Sending the request to somebody else’s computer adds a network round trip, a log entry, and a party who knows the result — while making the output no more random than it already was. When the result has a stake attached, that log entry is the whole problem: if a draw decides who wins something, a third party having seen it first is a property worth eliminating, not managing.

For passwords the argument is not a risk assessment at all, it is a definition. A password produced on a server has been seen by that server. Whether anyone looked depends on their intentions and their security; whether it was exposed is not in question. This is also why the password tool here keeps no history, while the coin and number tools deliberately do — a list of past draws makes those two auditable, and a list of past passwords would be a liability with no upside.

The QR code generator is the one deterministic tool in this group, so randomness is irrelevant to it — but the privacy argument survives in a different form. The thing worth protecting is the input, not the output: an unreleased campaign URL, an internal dashboard, a private document link. Pasting one into a remote generator hands it to a third party before you have published it.

Which one you want

For a two-way tie-break where both parties need to see that neither of them influenced it, use the coin flip. It keeps a running tally and converts the result into standard deviations, which is the number that actually tells you whether a source is behaving — a ratio on its own tells you almost nothing at short sample sizes.

For anything with more than two outcomes, or where you need several results at once, use the random number generator. Switch on no-repeats for raffles, seat assignments and lottery numbers, since those are draws without replacement and treating them as independent draws is simply the wrong operation.

For a credential, use the password generator, and let length do the work: entropy grows linearly with length and only logarithmically with the size of the character set, so one extra character buys more than another class of symbols. For a link, a Wi-Fi network or a contact card that someone will point a camera at, use the QR code generator — and download the SVG rather than the PNG if it is going to print, because a scaled-up bitmap has soft edges and soft edges hurt scan reliability.