Generators
Every Generators tool on Toolz.dev: 2 free utilities that run entirely in your browser. No signup, no uploads, no downloads.
Both tools here answer the same question in different shapes: give me a value nobody chose. The random number generator produces numbers in a range, with options for uniqueness and decimals. The list randomizer shuffles a list into a new order, or draws a given number of entries from it, which is how a giveaway winner gets picked.
What separates a usable randomiser from a toy is the two things people never check: where the randomness comes from, and whether the shuffle is unbiased. Both matter more than they sound, and both are invisible in the output.
What each generator produces
| Tool | Produces | Options |
|---|---|---|
| Random Number Generator | Numbers in a range | Unique-only, decimals, how many |
| List Randomizer | A shuffled list, or drawn entries | Shuffle the whole list, or pick n winners |
Where the randomness comes from
Most randomisers on the web call Math.random(), and it is worth knowing what that is. It is a pseudo-random generator, deterministic and seeded once per page context, implemented in V8 as xorshift128+. The output looks random and passes casual inspection, but it is not unpredictable: an observer with a run of outputs can recover the internal state and compute the rest of the sequence. The specification is explicit that it must not be used for anything security-related.
Both tools here draw from crypto.getRandomValues instead, the Web Crypto API, which is seeded from the operating system entropy pool and is not predictable from prior output. For picking a raffle winner in front of an audience this is the difference between a draw you can defend and one you cannot. It is also the same distinction that matters in the password generator, for much higher stakes.
A fair shuffle is a specific algorithm
The obvious way to shuffle - sort the list with a comparator that returns a random result - is biased, and famously so: the bias depends on the sorting algorithm, and Microsoft shipped a browser ballot screen in 2010 that used it and produced visibly uneven ordering. The correct method is the Fisher-Yates shuffle, which walks the list from the end and swaps each item with a randomly chosen one at or before it. Every permutation comes out equally likely, and it takes one pass.
The list randomizer implements Fisher-Yates for shuffling, and a separate path for drawing winners, because the two are different questions. Drawing without replacement means a name cannot win twice; drawing with replacement means each pick is independent. For a giveaway with several prizes, without replacement is nearly always what is meant, and it is worth being explicit about which you used when announcing a result.
Unique numbers, and what a draw does not prove
Asking for unique random numbers changes the problem: it is drawing without replacement from a range, so requesting more values than the range contains is impossible rather than slow, and requesting nearly all of them means the last few take many attempts if implemented naively. The random number generator handles that directly, which is the difference between generating five lottery numbers from 1 to 49 and generating five numbers that may repeat.
The honest limit of any browser-based draw is that it proves nothing to a sceptical audience. The result is computed on your device, so nobody else can verify what the input list was or that the output was not re-rolled. For a low-stakes giveaway that is fine and the transparency comes from recording the screen. For anything with real value or legal weight, use a service that publishes a verifiable seed and a timestamp before the draw. Both tools here run client-side, so the list of entrants stays on your device.
Frequently asked questions
- Is Math.random random enough?
- For a shuffle in a game, yes. For anything anyone might want to predict or contest, no: it is a deterministic pseudo-random generator seeded once per context, and its future output can be computed from a run of past output. The specification states it must not be used for security purposes. These tools use crypto.getRandomValues instead.
- How do I pick a giveaway winner fairly?
- Paste the entrant list, choose how many winners to draw, and draw without replacement so nobody can win twice. The shuffle uses Fisher-Yates, which makes every ordering equally likely, and the randomness comes from the Web Crypto API rather than Math.random. Record the screen if you need to show your working.
- Why is sorting with a random comparator a bad shuffle?
- Because the result depends on the sorting algorithm rather than on chance, so some orderings become far more likely than others. It is a well-documented bias, most visibly in the 2010 browser ballot screen that used it. Fisher-Yates is the correct algorithm and is no harder to implement.
- Can I generate random numbers with no repeats?
- Yes, with the unique option, which draws without replacement from the range. Requesting more numbers than the range contains is impossible by definition, so the tool bounds the request rather than looping forever. Without the option, each number is drawn independently and repeats are expected.
- Can these results be verified by someone else?
- No, and no browser-based tool can offer that. The draw happens on your device, so an outside observer cannot confirm the input list or that a result was not re-rolled. For a giveaway with real value, use a service that publishes a commitment to the seed before the draw and a timestamp afterwards.
- Is my list of entrants uploaded anywhere?
- No. Both tools run client-side, in your browser, so the names, emails or handles you paste stay on your device and nothing is transmitted or stored. That is worth knowing for a giveaway list, which is usually a list of real people who did not consent to it going anywhere else.