Random numbers — secure and reproducible

What makes a good random-number generator in 2026?

Three things separate honest randomness from sloppy randomness. First, the entropy source: a modern generator pulls bytes from the operating-system pool, not from a pseudo-random algorithm with a small internal state. Second, the distribution math: outputs are uniformly spread across the requested range, with no edge values quietly overrepresented. Third, the architecture: everything stays local, because random numbers for sensitive use-cases — tokens, salts, raffle results — should never travel through someone else’s hands.

This generator delivers all three. The default source is the Web Crypto API, which asks the operating system for cryptographically secure bytes. The range arithmetic uses rejection sampling, a standard technique recommended by NIST and used in production PRNGs. And the whole tool runs pure-client — Min, Max, Count and the result never leave your browser.

Why is Math.random() unsuitable for tokens and raffles?

Math.random() is not cryptographic. In the V8 engine — which powers Chrome, Edge and Node.js — the generator had a well-known state bug from 2015, described in detail by the Betable engineering team. Nick Forte and Mike Malone showed that after about 24 000 calls the sequence starts to collide — a property that is fatal for a fair online casino. The later fix to xorshift128+ does not make the generator secure either: the state is still small and observable, and several research teams have shown that after a few observed outputs the upcoming values can be reconstructed.

For a teacher’s group raffle Math.random() is more than enough. For a quiz game too. But for a session token, a password salt, an API key or a lottery quick-pick the source should be cryptographic. This tool makes the choice visible: the mode bar at the top reads “Secure · Web Crypto” by default, the second option “Reproducible · Seeded PRNG” is explicitly labelled non-secure.

What does seed mode buy you in tests and tutorials?

A seed is a starting value that makes a pseudo-random generator fully deterministic. The same seed always yields the same sequence. In seed mode this tool uses the Mulberry32 algorithm — a compact 32-bit PRNG variant (Tommy Ettinger, 2017) that is in the public domain and battle-tested in test frameworks.

Seed mode is useful for unit tests (“my lottery function should return 4, 12, 18, 28, 35, 41 with seed 42”), for tutorials where all participants need to see the same result, and for data-analysis demos that have to be reproducible. In the German-speaking market this feature is rare — many online generators offer only Math.random() draws with no control surface at all.

Important: seed mode is clearly marked as “not for security”. If you want to generate tokens in browser code, stick with crypto.getRandomValues.

How does the Lotto 6/49 preset work?

A click on the preset sets Min to 1, Max to 49, Count to 6 and duplicates to off. The generator then draws six distinct numbers from the pool, sorts them ascending and prints them as a comma-separated list. The Eurojackpot preset additionally draws two Euro numbers from the 1–12 pool. Both draws use the same Web Crypto source for full statistical fidelity.

What this generator deliberately does not do: statistics about “most-drawn numbers since 1955”, operator links, quick-pick ratings or winning promises. The probability of a 6-out-of-49 jackpot is about 1 in 13 983 816 — regardless of which combination you pick or how many statistics you stare at first. The tool is a generator, not a gambling lead.

Which output format fits which workflow?

The list format is the right choice when you paste the result into a chat, an email or a spreadsheet cell. CSV is ideal for Excel, Google Sheets, R, Python and any data-analysis pipeline that imports comma-separated values. JSON is the pick for web developers and API tests — the array drops straight into fetch() payloads or JSON.parse() calls.

For Eurojackpot draws the tool emits a structured output with primary and extra: list with line break, CSV as a two-row table, JSON as an object with numbers and extra arrays. The result is machine-readable without any post-processing.

What happens with very large ranges?

The supported range is bounded by Number.MAX_SAFE_INTEGER, giving 9 007 199 254 740 992 distinct values between Min and Max. Each draw consumes a 32-bit value from the Web Crypto API; ranges above 2³² simply use two draws in sequence. Performance stays linear in count: 1000 values from a 1–10⁶ range complete in under 10 ms on a typical 2026 laptop.

The upper bound on the count is 1000 numbers per click. That is enough for simulation-style use-cases (Monte Carlo tests, statistical distribution demos) while keeping the UI fluid even on weaker mobile devices. If you need more, click again or wrap the output in a loop of your own.

Are there use-cases this tool isn’t built for?

Yes, three. First: non-uniform distributions. Gaussian, Poisson, Beta and the rest are interesting for statistics students but too narrow a demand — and a proper statistics tool like R or Python’s numpy.random does it better anyway. Second: “true” randomness from atmospheric noise or quantum sources. Those require a server round-trip, which would break the pure-client doctrine. Web Crypto is plenty for every use-case short of strict scientific requirements. Third: no API endpoint, no embeddable widget. Anyone who needs random numbers inside their own tool should call crypto.getRandomValues directly — the tool here is the UI surface for end users.

What about privacy and GDPR?

Min, Max, Count and the result live entirely in the browser tab. There is no localStorage persistence, no cookies, no analytics, no server round-trip. The CSV/JSON download is built via a local Blob and triggered through an invisible <a download> element — the file lands directly on the user’s disk. Closing the tab discards the result; that is intentional.

From a GDPR perspective the tool processes no personal data in the sense of Art. 4 — lottery picks or dice rolls are not personal data. Even if the user enters employee IDs as the range, processing remains local and therefore outside the GDPR scope that applies to server-side data processing. The Secure-mode badge in the UI advertises that publicly.