Random Token / UUID Generator

Generates cryptographically secure UUIDs, hex tokens, Base64 tokens and API keys with the Web Crypto API, all client-side. Use these for API keys, session tokens, CSRF protection, database keys, webhook secrets — anywhere you need something unpredictable and unique.

UUID v4, and why the collision risk is a non-issue

A UUID v4 is a 128-bit random identifier in the familiar xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx format. The odds of generating a duplicate are roughly 1 in 5.3×10³⁶ — a number so large the collision risk isn't a practical engineering concern at any realistic scale. That's why UUIDs work well as primary keys in distributed databases where you can't coordinate sequential IDs across nodes, as REST API resource identifiers, and as correlation IDs for tracing a request across a distributed system.

Picking the right token type

• UUID v4 — database keys, API resource IDs, upload filenames. Human-readable-ish, database-friendly.
• Hex token (32 bytes) — CSRF tokens, session IDs, OAuth state parameters, webhook signing secrets
• Base64 URL-safe — JWT secrets, cookie values, anywhere a hex string would be awkwardly long
• Alphanumeric API key — user-facing keys where you want something that reads cleanly in documentation and doesn't look like line noise

The one rule that actually matters here

crypto.getRandomValues() — what this tool uses — is a CSPRNG seeded from real hardware entropy. Math.random() is not cryptographically secure and should never generate anything security-relevant; it's predictable enough that using it for a session token or CSRF token is a genuine, exploitable vulnerability, not a theoretical one. At 256 bits of entropy, tokens from a real CSPRNG are immune to brute force. And once you've got the key: never commit it to version control, use separate keys per environment, rotate on a schedule, and store the hash rather than the plaintext wherever you're persisting one server-side.