Secure Token Generator

Use hex for API keys, Base64 for session tokens, alphanumeric for anything user-visible

The encoding choice depends on where the token is going. Hex is the easiest to work with — no special characters, copy-pastes cleanly, and most libraries understand it natively. The tradeoff is size: 32 bytes of randomness becomes 64 hex characters, which is a bit long for a URL parameter. Base64 is more compact (43 characters for the same entropy) but has +, /, and = characters that need URL-encoding if they end up in query strings. Base64url avoids that problem and is what JWT uses. If a token is going to be shown to users — a one-time code, a temporary link — alphanumeric with ambiguous characters removed (no 0, O, I, l) is the most readable option. Length-wise, 32 bytes (256 bits) is appropriate for anything security-sensitive. Session tokens, CSRF tokens, API keys — all should be at least 128 bits. Anything shorter, especially numeric-only codes, is brute-forceable unless rate limiting is very strict.

All tokens here come from the Web Crypto API, not Math.random()

That distinction matters. Math.random() is not cryptographically secure — it's predictable given enough prior output, and some implementations are seeded from timestamps. crypto.getRandomValues(), which this tool uses, pulls from the operating system's entropy pool and is appropriate for generating secrets. The generated tokens are not stored or logged anywhere. There's no server call on generation — you can verify this in the network tab while clicking Generate and you'll see nothing go out.