toolhq.io

All posts
4 min readby Jameel Haider

Are UUIDs really unique

People treat UUIDs as if the universe guarantees they never repeat. That is a useful working assumption, but it is not literally true. A version 4 UUID is random, and anything random can in principle collide. The honest statement is that uniqueness is probabilistic, and the probability of a collision is so small that you can safely ignore it.

Where the randomness lives

A UUID is 128 bits. In version 4, six of those bits are reserved to mark the version and variant, which leaves 122 random bits. That gives about 5.3 times 10 to the 36th possible values. The question is not whether that space is large, it clearly is, but how many UUIDs you must draw before two of them are likely to match.

The birthday bound

The intuition most people get wrong is that you need to generate half the space before collisions matter. You do not. The birthday problem shows that collisions become likely at roughly the square root of the space, not half of it. For a space of size N, a collision is around 50 percent likely after about 1.2 * sqrt(N) draws.

N        = 2^122  (~5.3e36)
sqrt(N)  ~ 2.3e18

So you would need to generate roughly 2.6 billion billion UUIDs before reaching a coin flip chance of a single collision. To put that in human terms, generating one billion UUIDs every second, you would wait about 85 years to reach that 50 percent point.

A gentler way to state the risk: if you generate 103 trillion UUIDs, the probability that any two collide is about one in a billion. Most systems will never approach a fraction of that volume.

What actually breaks uniqueness

In practice, true random collisions are not the thing that bites you. The real failure modes are mundane.

  • A weak random source. If a UUID is built from a poorly seeded or predictable generator rather than a cryptographically strong one, the effective space shrinks far below 122 bits.
  • Copying IDs. Cloning a virtual machine image or restoring a database snapshot can duplicate identifiers that were never meant to be reused.
  • Truncation. Storing only part of a UUID, or using a non random version incorrectly, removes entropy.

The lesson is to trust a good generator and never shorten the value. If you truly cannot tolerate even an astronomically small collision chance, add a database unique constraint so a duplicate fails loudly rather than silently corrupting data.

You can generate well formed v4 UUIDs in the UUID & Token Generator. It uses the browser's cryptographic random source, and because everything runs locally, no identifier is ever sent anywhere. For the practical differences between versions, see UUID v1 vs v4.

The practical takeaway: UUID uniqueness is a probability, not a promise, but the birthday math puts any realistic collision far beyond reach. Spend your attention on using a strong random source and never truncating the value, not on the vanishing collision odds.