Random Token Generator

Tokens you can actually trust

A random token is a string used where unpredictability is the security property: session identifiers, password-reset links, API keys, CSRF tokens. The one requirement that matters is that it comes from a cryptographically secure random source, not a plain pseudo-random generator an attacker could predict or reproduce.

CSPRNG vs Math.random

Functions like JavaScript's Math.random() are fast but predictable: their internal state can be recovered from a few outputs, which is fatal for a token. Secure generators draw from the operating system entropy pool via crypto.getRandomValues or equivalent. The encoding (hex, Base64URL, alphanumeric) only changes how the bytes are printed, not the underlying randomness.

Example

16 random bytes = 128 bits
hex          -> 1f3c...  (32 chars)
Base64URL    -> Hzx...   (~22 chars, URL-safe)
alphanumeric -> a7Kp...  (no + / = to escape)

Base64URL swaps + / for - _ and drops padding, so a token drops straight into a URL without percent-encoding. Hex is longer but unambiguous and case-insensitive.

How many bits

For anything guard-worthy, 128 bits (16 bytes) is a sensible floor and 256 bits is generous. Resist the urge to shorten a token to make a URL prettier; every bit you cut halves the effort to guess it. If you need a collision-resistant id rather than a secret, a UUID is often the better fit.

FAQ

Can two secure tokens collide? At 128 bits the odds are negligible for any realistic volume. Collisions become a concern only with very short tokens or a weak source.

Is a UUIDv4 good enough as a token? It has 122 random bits, which is fine for uniqueness and acceptable as a secret, though a purpose-built token lets you choose length and encoding deliberately.