UUID Generator

What a UUID actually is

A UUID is a 128-bit identifier, rendered as 32 hex digits in five groups separated by dashes: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The current standard is RFC 9562 (May 2024), which obsoletes the 2005-era RFC 4122 and adds three new versions (v6, v7, v8).

The character at position 14 is the version digit (M above); position 19 holds the variant digit (N), which marks the layout as RFC 4122/9562-compliant. Those two bits of metadata are why a random UUID always starts with a 4 in its third block.

• 128 bits = 2¹²² usable random bits after fixing the version and variant fields
• Collision probability is astronomically low: ~2.3×10¹⁸ IDs before a 50% chance of any collision
• Format: 8-4-4-4-12 hex, always 36 characters including dashes

UUIDv4 vs UUIDv7 — random vs time-ordered

UUIDv4 fills 122 bits with cryptographically random data. It is uniform and collision-proof, but the IDs land in random order — terrible for a B-tree index, which fragments as rows arrive.

UUIDv7 (the headline addition of RFC 9562) fixes this: its first 48 bits are a Unix timestamp in milliseconds, the rest is random. Generated in sequence, v7 IDs sort naturally, so database indexes stay compact and range queries become possible. For most new systems with a database, v7 is the better default; v4 is still right when you want zero timing information leaked.

// v4 — pure random:
//   550e8400-e29b-41d4-a716-446655440000
//      position 14 = '4'  (version)

// v7 — millisecond timestamp first, then random:
//   0190a5f4-1e7b-7d4a-b3c2-9f8e7d6c5b4a
//      position 14 = '7'  (version)
//   sorts chronologically -> great for DB indexes

Why Math.random() must not generate UUIDs

A naive Math.random()-based UUID generator has two fatal flaws. First, Math.random() is not cryptographically secure — its output is predictable enough that an attacker who observes a few outputs can reconstruct the internal state and forge future IDs.

Second, browser engines seed Math.random() from a relatively small entropy pool in some edge cases. The correct primitive is crypto.randomUUID(), which draws from the operating system's CSPRNG and is guaranteed by the Web Crypto API to produce a spec-compliant v4 UUID.

// GOOD — cryptographically secure, spec-compliant:
crypto.randomUUID();   // -> "1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed"

// BAD — predictable, non-uniform, spec-violating:
// 'xxxxxxxx-xxxx-4xxx'.replace(/x/g, () => Math.floor(Math.random()*16).toString(16))