A UUID v4 contains random bits, so two independent generators can produce the same value.

How likely is that? The probability is very small when the random source works correctly.

Here is the arithmetic, followed by bugs that can produce duplicates much more directly.

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.

The v4 layout in RFC 9562 sets aside the other six bits for the version and variant.

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 50 percent collision threshold is about sqrt(2 × N × ln 2). That is 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 collision

That 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. The probability calculation assumes independent uniform random choices.

What about v7?

UUID v7 has 74 bits available for randomness or ordering fields. Collision risk depends on those choices and on values sharing the same encoded timestamp.

To reach a 50 percent collision chance you would need about 160 billion UUIDs inside one millisecond on the same clock, which is 1.18 times the square root of 2 to the 74. This figure assumes all 74 available bits are independent uniform randomness; generators using counters have a different allocation.

Values with different encoded timestamps cannot be equal because their timestamp bits differ.

This refers to the encoded timestamp, not a guarantee about two machines' wall clocks.

How collisions actually happen

Check these causes of duplicate IDs before blaming a random collision:

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. Check how your runtime initializes its cryptographic random source after cloning or restoring a machine.

Copy and paste. A developer copies a config block, including its UUID, and forgets to change it.

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?

Keep a database uniqueness constraint to catch duplicates.

A read before insert cannot prevent a concurrent writer from inserting the same value. If an insert fails, distinguish an existing record from a generated ID conflict before deciding whether a bounded retry is safe.

If you want to see just how different random UUIDs look, generate fifty at once with our UUID generator.

Compare the whole identifiers. Matching prefixes are possible and are not a collision unless the complete values match.