Everyone who first learns that a UUID v4 is just random bits asks the same question: what if two of them come out the same? The answer is that it is possible in theory and effectively impossible in practice. Here is the actual arithmetic, followed by the ways real collisions do happen, which have nothing to do with randomness.
How many UUIDs are there?
A v4 UUID has 122 random bits. That gives 2 to the power 122 possible values, which is roughly 5.3 times 10 to the 36. In words, about 5.3 undecillion. For comparison there are about 7.5 times 10 to the 18 grains of sand on Earth. You could give a unique UUID to every grain of sand on a billion billion Earths.
The birthday problem
Collisions are more likely than intuition suggests, because you are not comparing one new UUID against one old one. You are comparing it against every UUID ever generated. This is the birthday problem: in a room of 23 people there is a 50 percent chance two share a birthday, even though there are 365 days.
For a space of N values, the number of random picks you need before a collision becomes 50 percent likely is about the square root of 2 times N times ln 2, or roughly 1.18 times the square root of N. For 2 to the 122:
sqrt(2^122) ≈ 2.3 × 10^18
× 1.18 ≈ 2.7 × 10^18 UUIDs for a 50% chance of one collisionThat is 2.7 quintillion UUIDs. If you generated one billion per second, nonstop, it would take about 86 years to reach that count.
More useful: probability for a realistic count
Nobody wants a 50 percent chance. The approximate probability of at least one collision after generating n UUIDs is n squared divided by 2N.
| UUIDs generated | Chance of any collision |
|---|---|
| 1 million | 1 in 10^25 |
| 1 billion | 1 in 10^19 |
| 1 trillion | 1 in 10^13 |
| 103 trillion | 1 in a billion |
| 1 quintillion | about 1 in 10 |
Even a system that has produced a trillion IDs has a one in ten trillion chance of ever having seen a duplicate. You are far more likely to be hit by a cosmic ray flipping a bit in RAM.
What about v7?
UUID v7 has 74 random bits instead of 122, but the timestamp means you only compete with other UUIDs generated in the same millisecond. To reach a 50 percent collision chance you would need about 5 billion UUIDs inside one millisecond on the same clock. No real system does that. Across different milliseconds, collision is impossible because the timestamp bits differ.
How collisions actually happen
Every real world duplicate UUID story comes from a bug, not from bad luck:
- A weak random source. Older code using
Math.random()or a seeded PRNG can repeat. Always use the cryptographic generator:crypto.randomUUID(),os.urandom,/dev/urandom. - Cloned virtual machines. Two VMs booted from the same snapshot may start with the same random state and emit the same sequence. Cloud providers reseed on boot to prevent this, but home lab setups sometimes do not.
- Copy and paste. A developer copies a config block, including its UUID, and forgets to change it. This is by far the most common cause.
- v1 with a fake MAC and a reset clock. If two machines use the same fallback node ID and their clocks are wrong in the same way, v1 can repeat.
- Truncation. Someone stores only the first 8 characters "for readability". Now you have 32 bits and collisions become a real concern after about 65,000 IDs.
Should you add a uniqueness check?
A primary key constraint in the database costs nothing and catches the bug cases above, so keep it. But do not write retry loops that regenerate on collision, and do not query before insert to check. The check costs more than the risk it removes.
If you want to see just how different random UUIDs look, generate fifty at once with our UUID generator. Not one pair will share even a first group.