How Generate Random works

Every tool on this site produces a result in your browser, using randomness your browser supplies. No generator asks a server for an answer, and none of them uses an AI model to invent one. This page explains exactly how the results are produced, because “random” is a word that gets used very loosely and you should be able to check what we mean by it.

Where the randomness comes from

The great majority of tools — 774 of the 787 currently published — use the Web Crypto API's getRandomValues, the same cryptographically secure random number generator your browser uses for security-sensitive work. There is a single module in the codebase that talks to it, and every engine routes through that module, so there is exactly one place to audit and no generator quietly using something weaker.

Turning raw random bytes into a number in a range is where most implementations go wrong. Taking a random number modulo the range size skews the result towards the lower values, because the range rarely divides the number space evenly. We use rejection sampling instead: values that would fall into the uneven remainder are discarded and drawn again, so every value in the requested range is genuinely equally likely. Shuffles use Fisher–Yates driven by that same unbiased integer function, which is the standard method for producing every possible ordering with equal probability.

Why a spinning wheel never decides anything

11 tools show an animation — a wheel spinning, dice tumbling, a card turning over. In every one of them the outcome is chosen first and the animation is then calculated to land on it. The wheel does not spin and stop wherever friction takes it; the winner is drawn, and the rotation needed to point at that winner is worked out from the result.

This matters for two reasons. It means the animation cannot be influenced by how long you hold a button or how fast your device renders, and it means people who turn off animations get exactly the same distribution of results as everyone else. If your system is set to reduce motion, the animation is skipped and the result is shown immediately — the outcome is identical either way.

Secure randomness versus seeded randomness

2 tools offer an optional seed. These are the only tools on the site that behave differently, and the difference is deliberate: entering a seed switches that tool from the cryptographic generator to a small deterministic one, so the same seed with the same inputs reproduces the same output every time.

That is reproducibility, not security. A seeded result is not cryptographically random, and anyone who knows the seed and the inputs can work out the result in advance. It exists so a test fixture can be committed alongside the code that uses it, and so a league can publish a seed and let every member verify a draw afterwards. We say so on the pages that offer it, and no seeded mode is available on any password, passphrase, PIN or token generator — those always use the cryptographic generator, with no way to weaken them.

What “fair” does and does not mean here

When a tool says every option is equally likely, that is a statement about the selection method: the implementation draws uniformly, without bias towards any position in your list. It is not a promise about small samples. Ten spins of a four-name wheel will very often not give you two-and-a-half of each name; that is how independent random draws behave, not a fault in the tool.

Where a tool draws several results at once, the page says whether it draws with replacement (the same entry can come up more than once) or without (each entry appears at most once). Where a tool removes a winner between draws, that changes the odds for every remaining entry, and the page says so.

None of these tools is designed or tested for gambling, betting, prize draws with legal requirements, or any other setting where the fairness of a draw has to be demonstrable to a regulator. Tools that touch lottery number formats are unofficial and unaffiliated, and carry their own notes to that effect.

Where the word lists come from

Many generators draw from a curated list — names, prompts, activities, questions. Those lists are written and reviewed by us rather than scraped, and each one records its size, its source, its licence status and the date it was last reviewed. Generators built on a single list show a fixed sample of real entries and the size of the list on their page, so you can see what you would actually get before pressing anything.

The lists are checked automatically on every build for blank entries, duplicates, entries that break their length limit, and missing provenance. A list that fails those checks stops the build.

What happens to anything you type in

Tools that accept your own input — a list of names, a class register, team members, raffle entries, a topic — process it entirely in your browser. It is not uploaded, not stored on a server, and not placed in the page address, so sharing a link never shares your list.

Analytics receives event names and counts, never content. The event catalogue is a single typed list in the codebase, and payload fields that could carry user content are rejected at the point of sending rather than filtered later. The one tool that can optionally remember your input between visits — the classroom seating chart — is off by default, stores only in your own browser, and has a clearly labelled button to erase it. See the privacy policy for the full picture.

How this is kept honest

The randomness engines have their own unit tests, including distribution checks that would fail if a generator started favouring particular values. The catalogue itself is validated on every build: duplicate tools, broken links between tools, malformed or future review dates, and supporting text copied from one generator to another all fail the build rather than reaching the site.

If you find something on this site that contradicts anything on this page, that is a bug and we would like to know. Please report a problem and we will fix it or correct the page.