Random Token Generator

A random token is only as good as its source of randomness. JavaScript's Math.random uses an xorshift-class pseudo-random number generator that is fast and well-distributed but completely predictable from any captured output — using it for authentication tokens, API keys, password reset URLs, or session identifiers is a known vulnerability. This tool draws all bytes from window.crypto.getRandomValues, the Web Crypto API's CSPRNG, which browsers back with the operating system's secure random source (BCryptGenRandom on Windows, /dev/urandom on Linux, SecRandomCopyBytes on macOS).

Generation works by pulling a Uint8Array of random bytes, then mapping each byte onto your chosen alphabet using a power-of-two mask. Bytes whose value exceeds the alphabet length are rejected and resampled, which avoids the modulo bias that would otherwise make some characters slightly more likely than others. The end result is a uniformly random string at the entropy density of the chosen format.

Entropy is measured in bits and tells you how many guesses an attacker would need on average to find a matching token. A 32-character hex string has 128 bits of entropy (4 bits per nibble x 32) — comparable to a UUID v4 and beyond what current hardware can brute-force. A 64-character hex string is 256 bits, matching the strength of an AES-256 key. Base64-style alphabets pack 6 bits per character, so a 22-character Base64 token reaches roughly 128 bits of entropy in noticeably less space.

The four format choices map to the four common operational shapes. Hex is compact, copy-paste safe, and survives any encoding boundary — ideal for raw API keys, session secrets, and HMAC keys. Base64 URL-safe drops the +/= characters that need URL encoding and is best when you want short, dense tokens for query parameters or single-page-app session IDs. Alphanumeric is friendlier for human-readable references like invitation codes. Digits-only is the right choice for SMS OTPs and authenticator-style numeric verification flows.

Length matters. The minimum length to reach 128 bits of entropy depends on the alphabet: 32 hex characters, 22 Base64 characters, 22 alphanumeric characters, or 39 digits. For a 6-digit OTP code, the entropy is only about 20 bits — that is fine for a one-time code that expires in 60 seconds and tolerates only a handful of attempts before lockout, but it is far too weak for anything persistent.

Storage matters even more than entropy. Treat tokens like passwords: never log them, never store them in plain text, and compare hashes rather than raw values. For long-lived secrets, store SHA-256 of the token in the database and compare hash against hash. Rotate any token that may have leaked and invalidate it server-side immediately. The most common production incident is a token logged accidentally to an aggregator like Datadog or Sentry — guard against that at the logging layer, not by trying to remember.

All generation runs locally. The bytes never traverse the network, no analytics endpoint sees them, and closing the tab discards them. You can disconnect from the internet and the page will keep generating, since crypto.getRandomValues works offline.