How Our Random Generators Work

Browser-based randomness

All randomness is generated in your browser. No generated value is computed on a server, and no value is transmitted anywhere. That keeps latency at zero, keeps your input private, and makes the behavior of every tool auditable with the browser's own developer tools.

The Web Crypto API

Every tool calls crypto.getRandomValues(), the browser's cryptographically secure random generator. The browser seeds its generator from operating-system entropy sources, and the resulting values are suitable for cryptographic use — not just for games. This is the same API recommended for security-sensitive randomness on the web; see the MDN documentation for crypto.getRandomValues() for the platform-level details.

None of our production generator paths use non-cryptographic pseudo-random functions, and our test suite fails the build if such a call appears in the shipped source.

PRNGs and CSPRNGs

A pseudo-random number generator (PRNG) is an algorithm that expands a small seed into a long stream of numbers. Ordinary PRNGs — the kind behind a typical programming language's random() helper — are fast and statistically uniform, but their output becomes predictable once the seed or enough output is known. That is acceptable for cosmetic variation and simulations, and unacceptable where fairness claims or secrets are involved.

The Web Crypto API provides a cryptographically secure PRNG (CSPRNG) whose state is seeded and maintained by the operating system from entropy sources such as timing jitter and hardware events. It is designed so that observing previous outputs does not let an attacker predict the next ones. Every generator on this site uses that CSPRNG, which is why page state, call order and animation timing cannot influence results.

Rejection sampling and modulo bias

A secure 32-bit value spans 0 to 4,294,967,295. If you map it onto a range of, say, 100 values with a plain modulo operation, the first 96 values would be slightly more likely than the last four, because 4,294,967,296 is not divisible by 100. This is called modulo bias.

To avoid it, the integer sampler uses rejection sampling: it computes the largest multiple of the range size, discards any draw at or above that limit, and redraws. The remaining range is perfectly divisible, so every value in the requested range has exactly the same probability. For ranges larger than a 32-bit space, an equivalent BigInt sampler with the same rejection logic is used.

Unique sampling without repeats

When you request unique numbers, the tool must choose without replacement. For small and medium ranges it uses a partial Fisher–Yates shuffle: it builds the index range once, performs only as many secure swaps as there are requested values, and returns the first results. Every combination of values is equally likely.

For very large ranges with few selections — for example 5 unique numbers from 1 to 1,000,000,000,000 — allocating the whole range would waste memory, so a sparse algorithm (Floyd's algorithm) generates the same uniform sample in memory proportional to the number of selections. Requests that cannot be satisfied, such as 20 unique numbers from a 10-value range, return an explicit message instead of silently repeating values.

Decimals by integer scaling

Decimal values are produced by scaling the range to integers first. A request for two decimal places between 1 and 100 samples a secure integer between 100 and 10,000 and divides the result by 100. This avoids floating-point bias and keeps every representable value equally likely.

Coin flips, dice and wheel winners

The coin flip is a secure random 0 or 1, giving heads and tails equal probability. Dice rolls sample an integer from 1 to the number of sides with the same unbiased method — a D20 has exactly twenty equally likely outcomes, and dice notation modifiers are applied to the sum afterwards.

On the wheel, the winner is selected before the animation starts, using either equal probabilities or your custom weights. The animation then rotates to the segment that matches the already-chosen winner. Animation timing and frame rate can never change a result. Weighted selection uses a secure random value in a decimal range and picks the first segment whose cumulative weight passes the target.

Name and word datasets

The name generator uses the 1990 US Census given-name and surname files, which are public-domain US government data. The word generator uses the public-domain Moby Words II lists (the 1,000 most frequent words plus 74,550 common dictionary words), curated with a standard stopword filter; part-of-speech tags come from the openly licensed WordNet database. Sources are pinned by URL and SHA-256 hash in the build pipeline, which fails if any file changes.

Privacy

Generated values, pasted lists and passwords never leave your device. Local history is stored in your browser's own storage and can be cleared from each tool. If privacy-compatible analytics are enabled, they receive only event names and coarse parameters such as the tool name and quantity — never a generated value, a list item or a password.

Limitations and honest scope

• These tools are suitable for games, classroom activities, decisions, sampling and testing. They are not certified for regulated lotteries, gambling, cryptographic key generation, or any process requiring audited, certified hardware randomness. A certified process needs independent audit and certification that this website does not claim.
• Security depends on the browser and operating system providing sound entropy to crypto.getRandomValues(). We test our own code paths, not the platform's entropy source.
• Statistical uniformity means short sequences can still look surprising — streaks and clusters are expected and are not evidence of bias.
• The bundled name and word datasets reflect their public-domain sources (US name data from 1990; English word lists from the Moby project), not the entire world's names or vocabulary.