Token / API Key Generator

When to use each format?

• • Hexadecimal: API keys, session tokens, webhook secrets
• • Alphanumeric: verification codes, readable tokens
• • Base58: short URLs, tokens without ambiguous characters (no 0, O, I, l)
• • UUID v4: unique resource identifiers, database IDs

Authentication tokens, demystified

A token is an opaque string an authenticated client presents to a server in place of a username and password. Different systems use different shapes of token depending on lifetime, who issues them and what they protect:

• API keys — long-lived credentials issued to a project or machine; usually rotated manually.
• Bearer tokens (RFC 6750) — anything in Authorization: Bearer …; possession equals authorisation.
• Session tokens — server-side IDs stored in a cookie; revoked on logout.
• OAuth access tokens — short-lived (~1 h), tied to a specific scope and user.
• Refresh tokens — long-lived (30+ days), used only to obtain new access tokens.
• CSRF tokens — bound to a session and/or request, rotated on every form.
• Magic links — one-time tokens delivered by e-mail or SMS for passwordless login.

How much entropy is enough

OWASP recommends a minimum of 128 bits (16 bytes) of entropy for session tokens — that gives an attacker a 2¹²⁸ brute-force space. Cryptographic keys (signing keys, symmetric encryption keys) should aim for 256 bits (32 bytes). Encoding does not change the entropy, only the on-the-wire length: hex uses 2 chars per byte, base64 uses 4 chars per 3 bytes, base64url is URL-safe (no +, /, =), and base32 (Crockford variant) avoids ambiguous characters.

Common formats

UUIDv4 packs 122 effective random bits in a fixed 36-character layout. nanoid defaults to 21 URL-safe characters (~149 bits). ULID uses 26 characters and is time-sortable, useful as a primary key. For most session/API token use cases, a 32-character base64url string (192 bits) is the sweet spot between length and safety.

CSPRNG vs Math.random

Never generate production tokens with Math.random() — it is a fast PRNG seeded predictably and not cryptographically secure. Use the platform CSPRNG instead:

// Browser
const buf = new Uint8Array(32)
crypto.getRandomValues(buf)

// Node.js
require('crypto').randomBytes(32).toString('base64url')

// Python
import secrets; secrets.token_urlsafe(32)

// Java
new java.security.SecureRandom().nextBytes(buf)

Storing and rotating

Never log raw tokens, never commit them to git, and never expose them in URLs unless they are single-use. Keep them in environment variables or a secrets manager (Vault, AWS Secrets Manager, Doppler), rotate periodically and revoke compromised ones via a deny-list or by setting a short TTL. JWT is self-contained (claims signed by the server, validated stateless) while an opaque token is just a random string that requires a lookup on every request — opaque is simpler to revoke, JWT scales better at the cost of revocation complexity.

FAQ

Does this generator use a CSPRNG? Yes. It calls crypto.getRandomValues() in your browser, which is the Web Crypto API's cryptographically secure RNG.

Is it safe to use these tokens in production? Technically yes — the bytes are cryptographically strong — but the best practice is to generate tokens on the backend so they never travel through the front-end and never sit in browser history.

What length should I pick? 32+ URL-safe characters covers the vast majority of cases. Go longer (48–64) for refresh tokens and signing keys; UUIDv4 (122 bits) is acceptable for non-secret identifiers.