Can UUIDs Collide? Understanding the Odds

Published

Two independently generated UUIDs can be identical. For properly generated UUID v4 values, that risk is extremely small, but estimating it requires counting every pair of IDs, not just comparing one new ID with one old ID.

How many v4 values are possible?

A UUID has 128 bits, but v4 reserves six for the version and variant. That leaves 122 random bits, or 2^122 possible values, as described by RFC 9562, section 5.4. The calculation below assumes independent, uniformly distributed draws from that space.

The birthday calculation

With n IDs, there are n(n - 1) / 2 pairs that could match. Writing N = 2^122, the birthday approximation for at least one collision is:

p ≈ 1 - exp(-n × (n - 1) / (2 × N))

When the probability is small:
p ≈ n × (n - 1) / (2 × N)

The following estimates are calculated from that formula. They describe a collision anywhere in the entire collection, not the chance for just the next generated value.

Calculated UUID v4 collision estimates
Total UUIDs generatedApproximate collision probability
1 million9.4 × 10−26
1 billion9.4 × 10−20
1 trillion9.4 × 10−14

Solving the exponential approximation for a 50% probability gives about 2.7 × 1018 v4 UUIDs. A tiny probability is still different from a mathematical guarantee of uniqueness.

What the calculation does not cover

The formula cannot protect an application that reuses a cached ID, copies a fixture into production, truncates values, or accidentally returns the same ID for every row in a batch. Those are different failure modes from independent random collisions. When duplicates appear, inspect the complete generation and persistence path before attributing them to extraordinary bad luck.

Do not apply the v4 formula unchanged to v7. Its timestamp and optional monotonic fields change the model; IDs sharing a timestamp and the generator's behavior need separate consideration. Our v4 versus v7 guide explains the structural differences.

Make uniqueness a database rule

Use a primary key or unique constraint where duplicates would corrupt your data. Treat a constraint failure as an observable event. If your application retries with a fresh ID, keep retries bounded and ensure the failed attempt has not already triggered external side effects. Repeated failures deserve investigation.

For browser code, prefer the secure random generator behind crypto.randomUUID() over assembling IDs with Math.random(). Keep IDs intact through serialization, storage, and export.

Use the bulk UUID generator for sample data and the UUID validator to inspect formatting. Passing validation establishes neither global uniqueness nor the quality of the random source.


Browse all UUID articles →