Are UUIDs Unique? Collision Odds Explained

I ran a small experiment before writing this: generated ten million version 4 UUIDs in a tight loop and checked for a single duplicate. There wasn't one — and there almost certainly never would be, even if I let it run for the rest of my life. But the interesting part isn't that the check passed. It's that 'are UUIDs unique?' has a precise, slightly uncomfortable answer: no, not guaranteed — just improbably-collision unique. Those are different claims, and the gap between them is where the real engineering lives.

The honest answer: statistically, not absolutely

A version 4 UUID is built almost entirely from randomness. Nothing coordinates the machines generating them, and nothing checks a central registry afterward. So two independent generators could, in principle, produce the same value. Uniqueness here is a probability, not a promise.

That sounds alarming until you see the size of the number the probability is fighting against.

The math, one step at a time

A v4 UUID reserves 6 bits to mark its version and variant, leaving 122 bits of randomness. That's about 5.3×10³⁶ possible values — roughly five undecillion.

The relevant question isn't 'how many values exist' but 'how many must I draw before two match' — the birthday paradox. Just as a room needs only 23 people for even odds that two share a birthday (far fewer than 365), you need far fewer than 5.3×10³⁶ UUIDs for even odds of a collision. The threshold works out to about 2.71 quintillion (2.71×10¹⁸) UUIDs for a 50% chance of one collision.

To bring it below the scary threshold entirely: to reach even a one-in-a-billion chance of any collision, you'd have to generate roughly 103 trillion UUIDs.

The cosmic-scale analogy

Numbers this size stop meaning anything, so anchor them. If every one of the eight billion people on Earth generated a thousand UUIDs every second, it would take about ten thousand years to reach that 2.71-quintillion halfway mark. The count of distinct v4 UUIDs is comparable to a meaningful fraction of the atoms making up all life on the planet. You will run out of disk, run out of budget, and run out of century long before you run out of UUIDs.

So for the everyday question — can I treat a freshly generated UUID as unique? — the answer is a confident yes. Generate them one at a time or in bulk with the UUID Generator and you'll never see the math bite.

Where uniqueness actually breaks

Here's the twist the probability hides: real-world UUID collisions almost never come from exhausting the value space. They come from broken randomness.

• Weak generators. A UUID built on a non-cryptographic Math.random()-style source has far less real entropy than 122 bits, shrinking the space dramatically.
• Duplicated seeds. Fork a process, or spin up containers from a snapshot, and if each reuses the same RNG seed they'll march through the same 'random' sequence and emit identical UUIDs.
• Buggy libraries. Truncating, re-implementing, or mis-seeding a UUID routine has caused real duplicate-key incidents — none of which the birthday math predicts.

The lesson: the 122-bit space is not your risk. The quality of the randomness filling it is. Use a cryptographically secure generator — the same property that makes a random string generator or an API key trustworthy — and the theoretical odds actually apply.

When you want a guarantee, not a probability

Sometimes 'astronomically unlikely' isn't good enough — a collision on a financial ledger's primary key would be catastrophic even at one-in-a-quintillion odds. For those cases, don't rely on probability alone:

• Add a database unique constraint on the UUID column. It costs almost nothing and converts the impossible-but-disastrous collision into a caught, retryable error. It also catches the real failure mode — a bug emitting duplicates.
• Consider a coordinated scheme where absolute uniqueness matters more than decentralization — the classic trade-off laid out in UUID vs auto-increment IDs.
• Remember GUIDs are the same format, so the same odds apply whether your stack calls them GUID or UUID.

The takeaway

Are UUIDs unique? Not by guarantee — by overwhelming probability. A v4 UUID's 122 random bits make an accidental collision so unlikely that no real system will ever generate enough of them to worry, which is exactly why UUIDs work as decentralized keys. The failure you should actually guard against isn't the math running out; it's bad randomness making 'random' values repeat. Use a secure generator, add a unique constraint where a collision would be catastrophic, and you get the best of both: practical uniqueness you can rely on and a hard backstop for the one-in-a-quintillion case.