Generate UUIDs, tokens, and keys that follow the actual standards. Everything runs in your browser — nothing is sent anywhere.
Every backend service needs unique identifiers and random secrets. Database rows need IDs. APIs need keys. JWT auth needs signing secrets. Most developers reach for whatever is easiest: an auto-increment integer, Math.random(), or copying a token from Stack Overflow. All of those are mistakes in production. This tool generates tokens that follow the actual specifications, using the same cryptographic randomness your production code should use.
UUID v4 has been the default since 2005. It works. 122 random bits, near-zero collision probability, no coordination needed between servers. The problem: v4 values have no natural order. Insert a million rows with v4 primary keys and your B-tree index fragments because new values land at random positions.
UUID v7 fixes this. Ratified as RFC 9562 in 2024, it puts a millisecond timestamp in the first 48 bits. Values sort chronologically. Your database index stays compact, range queries work, and you can extract a rough creation time from the ID itself. The remaining 74 bits are random, so uniqueness holds. If you're starting a new project, v7 is the better default.
128 bits (16 bytes) is the bare minimum for a secret that protects anything. 256 bits is the standard recommendation. The encoding you pick changes the string length but not the security: 32 random bytes become 64 hex characters or 43 base64url characters. Same entropy, different representation. For JWT HMAC secrets, RFC 7518 sets the floor: the key must be at least as long as the hash output. That means 32 bytes for HS256, 48 for HS384, 64 for HS512.
Every value starts with crypto.getRandomValues(), the Web Crypto API built into all modern browsers. It draws entropy from the operating system, the same source that /dev/urandom on Linux or CryptGenRandom on Windows uses. For structured identifiers (UUID, ULID, ObjectId, KSUID), random bytes are combined with timestamps and version bits per each specification. Nothing is sent to any server. Nothing is logged.
A 128-bit identifier designed to be unique without a central authority. UUID v4 uses 122 random bits. UUID v7 (RFC 9562, finalized 2024) adds a timestamp so values sort chronologically. Collisions are so unlikely that for most purposes you can treat them as impossible.
UUID v4 is pure random. UUID v7 starts with a 48-bit millisecond timestamp, so values sort chronologically. Use v7 when ordering matters: database primary keys, event IDs, anything you'll query by time range. Use v4 when it doesn't.
Yes. crypto.getRandomValues() is a cryptographic random number generator that pulls entropy from the OS. It's the same source that server-side libraries use. Nothing leaves your browser: no network request, no server, no logging.
RFC 7518 sets the minimum: HS256 needs at least 32 bytes, HS384 needs 48, HS512 needs 64. The key must be at least as long as the hash output. This tool generates keys at exactly those sizes.
A 128-bit identifier that combines a 48-bit timestamp with 80 random bits, encoded as 26 Crockford Base32 characters. It sorts chronologically like an auto-increment ID but generates uniquely across distributed systems like a UUID. Use it when you need both properties.
Hex is the most readable. Base64url is shorter and URL-safe. Base64 is shorter but needs escaping in URLs. The entropy is identical: encoding only changes the string representation, not the randomness underneath.
It calls crypto.getRandomValues(), which draws entropy from the operating system's cryptographic RNG. For structured formats (UUID, ULID, ObjectId), it combines random bytes with timestamps and version bits per the relevant spec.
Yes. Every output conforms to its specification and uses cryptographically secure random bytes. The one consideration: for high-security secrets (encryption keys, root credentials), some teams prefer generating on the target machine rather than copying from a browser tab.