What Is a UUID and When Should You Use One?

A UUID is a 128-bit value, conventionally shown as 32 hexadecimal digits in five groups separated by hyphens (8-4-4-4-12). That is an enormous space — about 3.4 × 10^38 possible values. Several versions exist: version 1 embeds a timestamp and machine identifier, version 4 is almost entirely random, and newer version 7 puts a timestamp at the front so IDs sort by creation time. The format is the same; only how the bits are chosen differs.

Version 4 UUIDs fill 122 of their bits with random data (the rest mark the version and variant). Because the space is so vast, two independently generated v4 UUIDs practically never collide — you would need to generate billions per second for many years before a clash became likely. This is what makes them so handy: two servers, a phone offline on a plane and a background job can all mint IDs at the same time, with no shared counter, and safely merge their records later.

UUIDs are not free. They are larger than a simple integer, less friendly as a database primary key (random v4 values scatter across an index and can hurt insert performance), and awkward for humans to read or dictate over the phone. If a single database already assigns your IDs and you never need to generate them elsewhere, a plain auto-incrementing integer is smaller and faster. Reach for a UUID when independence matters — offline clients, merging data sources, or hiding how many records you have — and consider version 7 when you also want time-ordered keys.

A version 4 UUID carries 122 random bits — the other six are fixed by the version and variant fields — so there are about 5.3 × 10^36 of them. The useful question is not how many exist but how many you can generate before two match, and the birthday bound answers it: collisions become likely at roughly the square root of the space, around 2.3 × 10^18 values.

In practical terms you could generate a billion UUIDs a second for about seventy years and still face only a one-in-a-billion chance of a single duplicate. That holds only while the bits are genuinely random, which is why a UUID built on Math.random() is a real bug: browsers have shipped generators with far less internal state than 122 bits, making duplicates plausible inside a single session.

Random UUIDs scatter. Insert a million of them as the primary key of a clustered-index table and each row lands on a random page, which fragments the index, spoils cache locality and can slow inserts by an order of magnitude compared with an auto-incrementing integer.

UUID version 7, standardised in RFC 9562 in 2024, fixes that by putting a 48-bit millisecond timestamp in the leading bits and filling the rest with randomness. Values generated later sort after values generated earlier, so inserts append instead of scattering, while the random tail keeps them unguessable across systems. ULID and Snowflake IDs solve the same problem with different layouts.

Because version 4 UUIDs are unguessable, they are often used as capability links: a share URL nobody can enumerate. That works, but only as long as the value came from a cryptographic generator, does not leak in a referrer header, and is not printed in an email that gets forwarded.

Other versions leak more. Version 1 embeds a timestamp and, in its original form, the machine's MAC address, which has been used more than once to identify the author of a document. If you need a secret, generate a secret and say so; if you need an identifier, a UUID is an identifier.