UUID collision probability
A UUID v4 carries 122 random bits, so reaching a 50% chance of a single duplicate takes about 2.7 × 10^18 values — a billion every second for 86 years. Below is the maths, a calculator for your own numbers, and why every real-world “collision” turns out to be a bug.
By the Withuse team · Updated
Calculate it for your scale
Generating 1 × 10^9 identifiers in total, across all time.
Negligible. You are far more likely to be hit by a meteorite today.
A 50% chance would need about 2.71 × 10^18 identifiers in total, across all time.
The calculator applies the birthday approximation described below. Everything runs in your browser — no numbers are sent anywhere.
The numbers at a glance (UUID v4)
| UUIDs generated | Chance of one collision | Comparable to |
|---|---|---|
| 1 million | 1 in 1.1 × 10^25 | Not a meaningful quantity |
| 1 billion | 1 in 1.1 × 10^19 | Far below silent memory-error rates |
| 1 trillion | 1 in 1.1 × 10^13 | Still negligible for any single system |
| 1 quadrillion | 1 in 1.1 × 10^7 | Roughly a lottery jackpot |
| 2.7 quintillion | 50% | Even odds — the birthday bound |
Where the formula comes from
This is the birthday problem. With n values drawn from a space of N possibilities, the probability that at least two match is approximately 1 − e^(−n²/2N), and the halfway point sits at n ≈ 1.1774 × √N. For UUID v4, N = 2^122 because four bits are spent on the version and two on the variant, leaving 122 for randomness. That gives √(2^122) = 2^61, and multiplying by 1.1774 produces the 2.7 × 10^18 figure quoted everywhere.
The counter-intuitive part is that the answer scales with the square root of the space, not the space itself. Doubling your random bits does not double the safe volume — it squares it.
Why v7 is safe with fewer random bits
A UUID v7 spends its first 48 bits on a Unix millisecond timestamp, leaving 74 random bits rather than 122. In isolation that is a much smaller space, but the timestamp acts as a partition: two values created in different milliseconds differ in their leading bits and cannot collide regardless of what follows. The question therefore narrows to how many identifiers you mint inside one millisecond, and even odds there require about 1.6 × 10^11 — 162 billion in the same millisecond. The same reasoning applies to ULID, which reserves 80 bits for randomness behind an identical 48-bit timestamp.
Real collisions are implementation bugs
When duplicates genuinely appear in production, the cause is a broken random source rather than exhausted entropy. The recurring patterns:
- A non-cryptographic generator. Snippets built on
Math.random()produce predictable, repeatable output. Use crypto.randomUUID() instead. - Forked process state. A parent seeds a generator, then forks; both children continue from the same state and emit the same sequence.
- Restored VM snapshots. Rolling back to a snapshot replays the entropy pool, so the machine regenerates identifiers it has already issued.
- Early-boot embedded devices. Identifiers minted before the kernel has gathered entropy come from a nearly empty pool.
All four are detectable the same way: keep the unique constraint your primary key already gives you, and treat a violation as an alert about the generator rather than an unlucky draw.
Frequently asked questions
How likely is a UUID collision?
For UUID v4, vanishingly unlikely. The version carries 122 random bits, which gives about 5.3 × 10^36 possible values, and the birthday problem says you need roughly 2.7 × 10^18 of them before reaching a 50% chance of a single duplicate. To put that in working terms: generating a billion UUIDs every second, it would take around 86 years to reach even odds. At more realistic volumes the numbers stop being meaningful — a billion values in total carries a collision probability near 1 in 10^19, which is far below the rate at which your server's memory silently flips a bit. The practical answer is that v4 collisions are not a risk worth engineering around.
How do you calculate UUID collision probability?
Use the birthday problem. With n values drawn from a space of N possibilities, the chance of at least one collision is approximately 1 − e^(−n²/2N). For UUIDs, N is 2 raised to the number of random bits: 122 for v4, since four bits encode the version and two the variant. Rearranging for the halfway point gives n ≈ 1.1774 × √N, which is where the familiar 2.7 × 10^18 figure for v4 comes from. The same formula covers any random identifier if you substitute its bit count — 74 for UUID v7 and 80 for ULID, both of which apply per millisecond rather than globally, because their timestamps separate values generated at different times.
Is UUID v7 more likely to collide than v4?
Per identifier it has fewer random bits, but the comparison is not like for like. A v7 value spends its first 48 bits on a millisecond timestamp, leaving 74 random bits against v4's 122. That sounds much weaker until you notice the timestamp acts as a partition: two v7 values created in different milliseconds cannot collide at all, no matter what their random parts contain. So the question becomes how many identifiers you create within a single millisecond, and reaching a 50% chance there needs about 1.6 × 10^11 — 162 billion in the same millisecond. No real system approaches that, which is why v7 is considered collision-safe despite the smaller random field.
Has a UUID collision ever actually happened?
Reported cases exist, but they trace back to implementation defects rather than exhausted entropy. The recurring causes are all variations on a broken random source. A library falls back to a seeded pseudo-random generator such as Math.random() instead of a cryptographic one, so its output is predictable and repeats. A process forks after seeding, and both children continue from the identical random state. A virtual machine snapshot is restored repeatedly, replaying the same entropy pool each time. Embedded devices generate identifiers at first boot before the kernel has gathered enough entropy. In every case the fix is the same: use your platform's cryptographically secure source, which is what this site's generator does.
Should I add a unique constraint on a UUID primary key column?
Yes, though not because you expect a collision. Declaring a column as the primary key already creates the constraint, and the index it builds is what your queries use anyway, so the protection is free. Its real value is catching the failure modes above: if a deployment ships with a broken random source, a unique violation surfaces the bug immediately and loudly instead of letting duplicate identifiers quietly corrupt relationships between tables. Treat it as an assertion about your generator rather than a hedge against probability. What is not worth doing is a pre-insert SELECT to check whether an identifier already exists, which doubles your query load to guard against odds of roughly 1 in 10^19.
References
Want to see the entropy for yourself? Generate up to 1,000 UUIDs at once with our free UUID generator — every value is produced in your browser by the Web Crypto API. Related: UUID v4 vs v7 · UUID length & structure