Random Token Generator

Why Math.random() is not allowed near a token

A security token is only as strong as the randomness behind it, and JavaScript's Math.random() is not cryptographically secure. It is a fast pseudo-random generator (typically xorshift128+) seeded from a small internal state that an observer can reconstruct from a handful of outputs — meaning future and past values become predictable. That is fine for shuffling a carousel and a disaster for an API key or a password-reset token. This tool draws every byte from the browser's crypto.getRandomValues, the CSPRNG backed by the operating system's entropy pool.

The difference is not academic. Real breaches — leaked session tokens, guessable coupon codes, forgeable reset links — have traced directly back to Math.random() or to home-grown generators seeded with the current timestamp. If an attacker can guess the seed, they can enumerate every token you will ever issue. A CSPRNG removes that shortcut: the only attack left is brute force, and that is governed entirely by length.

Entropy and length: how much is enough

Token strength is measured in bits of entropy, and each character contributes only as many bits as its alphabet allows. A hexadecimal character carries 4 bits; a Base62 (a–z, A–Z, 0–9) character carries about 5.95 bits. So a 32-character hex token is 128 bits, while 32 Base62 characters is roughly 190 bits. As a rule of thumb, 128 bits is the floor for anything an attacker can attack offline or at scale — it is the same security level as AES-128 and is far beyond any feasible brute-force search.

More characters never hurt; fewer than ~128 bits of true entropy is where bearer secrets start to get risky.

Where tokens leak — and it is rarely the algorithm

• URLs: a token in a query string lands in server access logs, browser history, the Referer header sent to third parties, and analytics. Put bearer secrets in an Authorization header or POST body, never in a link.
• Logs and error trackers: stack traces and request dumps routinely capture full headers. Redact tokens before they reach Sentry, CloudWatch or a log aggregator.
• Source control and chat: a key pasted into a commit, a .env that escapes .gitignore, or a token dropped in Slack lives there forever — public GitHub is scraped for keys within minutes.
• Client-side code: anything shipped to the browser is readable. A secret in front-end JavaScript is not a secret; only public/publishable keys belong there.
• Screenshots and screen-shares: a visible token in a demo or support ticket is a disclosed token. Treat it as compromised.

Rotation, scoping, and what a random string can't do

Generating a strong token is step one; the lifecycle is what keeps it safe. Give every token the narrowest scope it needs and an expiry, so a leak is bounded in both power and time. Rotate on a schedule and immediately on any suspected exposure — and design so that two keys can be valid at once during a cutover, or rotation becomes an outage and never happens. Keep a record of which key is used where, because you cannot revoke a credential you cannot find.

Finally, remember what a random token is not: it is an opaque bearer secret, not a signed, self-describing credential. It carries no identity, no expiry and no permissions on its own — your backend must store and check those. If you need a token that travels with its own claims and signature, that is a different tool — see the JWT decoder. For a stable, non-secret identifier, reach for a UUID instead.