UUID Generator

A UUID (Universally Unique Identifier) is a 122-bit value, typically written as 32 hexadecimal digits in five groups separated by hyphens: 8-4-4-4-12. The version digit — the first character of the third group — tells you how the remaining bits were generated. That single digit is the key to understanding the trade-offs between versions.

v1 combined a 48-bit MAC address with a 60-bit timestamp, giving you time-ordered IDs that also revealed the machine that generated them. v4 is pure randomness — 122 bits drawn from a cryptographically secure source. v7, the newest widely adopted version, puts a 48-bit millisecond timestamp in the high bits and fills the rest with randomness. The version you choose determines whether your IDs are sortable, whether they leak metadata, and how they behave as database keys.

v4 UUIDs are generated entirely from random data: set the version bits to 0100, set the variant bits to 10, and fill the remaining 122 bits from a cryptographically secure random source. The result has no structure, no ordering, and no relationship to any external system. This is why v4 has become the default choice for public identifiers — it's simple, it's unpredictable, and it carries zero information about the machine or moment of creation.

The randomness is also v4's main weakness as a database key. Because consecutive v4 UUIDs share no prefix relationship, inserting them into a B-tree index causes the index to split pages at random positions across its entire range. On a heavily written table this leads to poor cache utilization and higher write amplification — the database is constantly touching pages that were recently evicted.

v7 was designed specifically to fix v4's database problems. The first 48 bits store a Unix timestamp in milliseconds, so every UUID sorts lexicographically in creation order. The remaining 74 bits are random, which means two UUIDs generated in the same millisecond are still effectively unique. For a B-tree index, this means new rows always append to the rightmost edge of the index — the same access pattern as an auto-incrementing integer.

The trade-off is that v7 IDs leak their creation timestamp. For many applications this is harmless or even useful (you can derive an approximate creation time from the ID itself), but it's worth knowing before you expose v7 UUIDs publicly. If you need both sortability and privacy, v4 remains the safer default; if you need sortability and don't mind the timestamp, v7 is strictly better for index performance.

The birthday paradox sets the collision probability for random IDs: with 122 bits of randomness, you'd need to generate roughly 2^61 UUIDs before a 50% chance of any collision. That's about 2.3 quintillion IDs — billions per second for tens of thousands of years. No real-world system comes close. Even at planetary scale, the probability is so low that engineers routinely treat v4 collision as impossible rather than merely improbable.

The only real collision risk comes from a broken random number generator, not from the bit space. If a generator reuses its internal state or has insufficient entropy, the effective randomness collapses and collisions become likely. This is why UUID generators should always use crypto.getRandomValues() (in the browser) or /dev/urandom (on servers) rather than Math.random(), which is not cryptographically secure and may produce predictable or repeating sequences.

UUID isn't the only option. nanoid generates URL-safe IDs from a 64-character alphabet (A-Za-z0-9_-) and packs more entropy per character than hexadecimal — a 21-character nanoid has roughly the same 122 bits of randomness as a v4 UUID but is shorter and URL-safe without modification. nanoid is popular in JavaScript ecosystems because it's compact and dependency-free.

ULID (Universally Unique Lexicographically Sortable Identifier) takes a different approach: 48 bits of millisecond timestamp plus 80 bits of randomness, encoded in Crockford Base32. ULIDs share v7's time-ordered property but use a different encoding and bit layout. The practical differences come down to ecosystem support — UUID has native database types in PostgreSQL, MySQL, and SQL Server, while nanoid and ULID typically live in string columns. Choose based on your stack's support and whether you need the sortability that v7 and ULID provide.