CSPRNG Random Number Generator for UUID, HEX, Base64

Randomness has two faces. One is statistical spread: dice should not keep landing on one face, and coin flips should not drift wildly toward one side. Drawings, ordering, and small simulations mostly care about this absence of visible bias.

The other face is unpredictability under observation. Login codes, password-reset tokens, API secrets, and session IDs need more than a tidy-looking distribution. An attacker who sees some values should not be able to guess the next one, reconstruct past or future output, or infer the generator state. That is where a CSPRNG, a cryptographically secure pseudorandom number generator, becomes relevant.

OWASP describes CSPRNG-backed generation as necessary for session identifiers and security-sensitive random values. In other words, a random number generator moves into a different quality class as soon as authentication or authority is involved.

The word pseudorandom sounds suspicious at first. Most computer random number generation does not read a fresh natural event for every bit. It seeds internal state with hard-to-predict material from the operating system or platform, then expands that state through cryptographic processing.

If the state is the same, the output is deterministic. Even so, if an outside observer cannot recover the state or compute the next output from prior output, the generator is practically unpredictable. NIST SP 800-90A Rev.1 covers DRBG mechanisms, while 90B covers entropy sources and 90C covers RBG constructions that combine them.

This tool does not invent its own random number algorithm. It delegates that work to the browser and operating system. It uses crypto.getRandomValues() for cryptographically strong random bytes and crypto.randomUUID() when UUID v4 output is requested.

More precisely, the tool is not itself the CSPRNG. It uses the CSPRNG-grade random source exposed by the browser. The exact algorithm and entropy source depend on the browser, operating system, and implementation. The Web Cryptography specification does not mandate a single minimum entropy figure; it expects user agents to use well-established PRNGs seeded with high-quality entropy.

getRandomValues() cannot fill more than 65,536 bytes in one call, so this implementation chunks requests internally. randomUUID() is available in secure contexts such as HTTPS. getRandomValues() is the unusual Crypto member that may be used outside secure contexts, but a real random-number page should still be served over HTTPS to reduce tampering risk.

Math.random() is useful, but it is not designed for cryptographic security. It is fine for visual effects, minor game variation, and simple shuffling where security does not depend on unpredictability.

Secrets and authentication-related values need outputs that attackers cannot predict. MDN explicitly tells developers not to use Math.random() for security-related work and to use the Web Crypto API, specifically crypto.getRandomValues(), instead. That is the first fork in the road: randomness that looks mixed and randomness that resists prediction are different things.

Using Web Crypto is not the end of the story. Suppose you have one uniformly random byte, so values from 0 to 255 are equally likely, and you want an integer from 1 to 100. A simple remainder looks attractive, but 256 values do not divide evenly into 100 buckets.

Values corresponding to 0 through 55 would have three source values each, while 56 through 99 would have two. The earlier outputs would be 1.5 times as likely. That is modulo bias.

Strong raw randomness can still bend at the final conversion step. Rejection sampling avoids that by accepting only the source values that map evenly to the requested range. For 0 to 255 into 1 to 100, values 0 to 199 map cleanly; 200 to 255 are discarded and redrawn. The discard looks wasteful, but it buys fairness.

Output format matters. HEX carries 4 bits per character, so 16 bytes, or 128 bits, becomes 32 characters. It is readable in logs and configuration, but longer than denser encodings.

Base64 carries 6 bits per character, but normal Base64 can include +, /, and =. For URLs and APIs, Base64URL replaces + with - and / with _, and RFC 4648 defines it separately from ordinary Base64.

UUID v4 is widely used as an identifier. crypto.randomUUID() creates UUID v4 values with 122 random bits after fixed version and variant bits. That is useful for collision-resistant identifiers, but a UUID is still an ID, not a universal secret key. RFC 9562 warns against using UUID possession itself as an access-granting security capability.

Tokens center on unpredictability. If knowing the value grants authority, as with a password-reset URL or temporary API access value, the system also needs enough entropy, expiration, storage controls, invalidation, and logging.

Verification codes are short because humans type them. A 6-digit code has one million possibilities, about 20 bits. CSPRNG generation keeps the distribution fair, but the security comes from short lifetimes, attempt limits, and abuse controls.

Salts are usually not secrets. Their job is to keep equal passwords from producing equal-looking hashes and to avoid reuse across users or records. CSPRNG generation is a good choice, but a visible salt is not automatically a breach.

A nonce is a value used once. For some cryptographic modes, never reusing a nonce under the same key matters more than unpredictability. Random nonces can collide if too short; counters may fit some protocols better. OWASP treats IVs and related attributes as mode-dependent values that cryptographic libraries should handle where possible.

Encryption keys require even more care. This tool can produce random bytes, but a key is not just text copied into a field. Algorithms, purpose, extractability, storage, rotation, and destruction all matter. For Web Crypto key generation, use generateKey() rather than hand-copied getRandomValues() output.

Unique drawings have a different hard limit. You cannot draw 11 unique values from 1 to 10. That is not an implementation detail; it is mathematically impossible. This tool warns instead of silently accepting impossible conditions, and it caps huge unique ranges to avoid excessive memory or processing time.

The point of this tool is clear: use Web Crypto instead of Math.random(), use rejection sampling for ranged integers, explain HEX, Base64URL, and UUID v4 as different formats, avoid presenting UUID v4 as a magic secret, separate the guarantees needed for tokens, verification codes, salts, and nonces, warn on impossible no-duplicate requests, and leave actual encryption keys to key-generation APIs.

The ending is simple but important. Secure randomness is not decided by one API call. Use a strong source, avoid bias in range conversion, rate-limit short codes, never reuse nonces where the mode forbids it, do not mistake UUIDs for secrets, and manage keys as keys.

Randomness often fails at the exit, not the entrance. The value of a CSPRNG is not only that the water source is strong; it is that the water reaches the last drop without being bent on the way out.