Generate & Decode UUID v4, UUID v7 and ULID Identifiers
Cryptographically strong identifiers created entirely in your browser with WebCrypto. Bulk-generate, copy, and reverse the embedded timestamp out of any time-ordered ID. Nothing is sent to a server.
How each identifier is built
Every ID here starts from crypto.getRandomValues(), the browser's CSPRNG, so the random bits are suitable for security-sensitive keys, tokens, and database primary keys. The three formats differ only in how those bytes are arranged.
UUID v4 is the simplest: fill a 16-byte buffer with randomness, then overwrite two nibble fields. The 4 high bits of byte 6 are set to 0100 (version 4) and the 2 high bits of byte 8 are set to 10 (the RFC 4122 variant). Concretely: b[6] = (b[6] & 0x0f) | 0x40 and b[8] = (b[8] & 0x3f) | 0x80. That leaves 122 random bits, which is why v4 collisions are astronomically unlikely.
UUID v7 makes IDs sort by creation time. The first 48 bits are the current Unix time in milliseconds (Date.now()), written big-endian into bytes 0-5. The version nibble in byte 6 becomes 0111 (7) and the variant bits in byte 8 stay 10; the remaining 74 bits are random. Because the timestamp lives in the most significant bytes, lexicographic order equals chronological order — ideal for index locality in Postgres or MySQL.
ULID packs the same 48-bit millisecond timestamp plus 80 random bits into a 128-bit value, then renders all 26 characters in Crockford Base32 (alphabet 0123456789ABCDEFGHJKMNPQRSTVWXYZ, which drops I, L, O and U to avoid ambiguity). The first 10 characters encode the time; the last 16 encode the entropy. Decoding is just the inverse: read those first characters back as a base-32 number of milliseconds and convert to a UTC date, which the decoder above does live as you type.
All generation is client-side and offline. Increase the count to stress-test bulk creation, switch case for systems that expect uppercase, and paste any v7 or ULID into the decoder to confirm the timestamp round-trips.