UUID Generator (v4 random, v7 time-ordered)

When to use v4 vs v7

UUID v4 is purely random — 122 random bits with two version/variant bits, giving about 5.3 × 10³⁶ possible values. Two are basically guaranteed to never collide. Use v4 anywhere you don't need ordering, like API request IDs or anonymous user identifiers.

UUID v7 (RFC 9562, published in 2024) starts with a 48-bit Unix millisecond timestamp followed by 74 random bits. They sort lexicographically in creation order, which is huge for database performance — primary keys that sort by time mean inserts always go to the end of the B-tree, no random page splits. Use v7 for new database primary keys.

How this generator works

Both v4 and v7 use crypto.getRandomValues — the browser's secure random source, the same primitive used by HTTPS and password managers. v4 fills 122 bits randomly. v7 splits 48 bits of timestamp + 74 bits of random plus version/variant markers per the RFC.

Generation happens in your browser. The UUIDs are not stored or transmitted. If you generate 100 v4 UUIDs the chance of a collision among them is astronomically small — well below the chance of cosmic rays flipping bits in your CPU.

Common UUID gotchas

v4 UUIDs as database primary keys hurt performance compared to auto-incrementing integers because random values cause B-tree page splits during inserts. v7 fixes this — use v7 if you want UUID benefits without the index pain.

Don't expose UUIDs to users where guessability matters. v4 UUIDs have 122 bits of entropy and are unguessable. v7 UUIDs leak creation time, which is fine for most uses but bad if creation time is sensitive.

UUIDs are 36 chars including hyphens (32 hex + 4 hyphens). They take 16 bytes binary or 36 bytes text. For very high-cardinality columns, consider storing as binary BLOB / UUID native type rather than VARCHAR(36).