UUID Collision Probability: Can Two UUIDs Ever Match?

"Are UUIDs really unique?" is one of the most common questions developers ask before trusting them as identifiers. The honest answer is: not guaranteed unique, but unique enough that a collision is something you will almost certainly never see — provided you generate them correctly.

This article explains the actual probability of a UUID collision, the math behind it (the famous birthday problem), the realistic ways duplicates do sneak in, and how to keep your IDs safe. You can generate cryptographically random identifiers any time with the UUID Generator or the dedicated UUID v4 Generator.

The Short Answer

A version-4 UUID has 122 bits of randomness, which gives roughly 5.3 × 10^36 possible values. To reach a 50% chance of any collision, you would need to generate about 2.71 × 10^18 UUIDs — that is 2.7 quintillion. At one billion UUIDs per second, hitting even-odds would take roughly 86 years of nonstop generation.

For any realistic application, a random UUID collision is not a risk worth engineering against. The duplicates teams actually encounter almost always come from bugs — a broken random source, a copied seed, or accidental reuse — not from the math.

Why UUIDs Are Not "Guaranteed" Unique

A UUID is a 128-bit number. In version 4, six of those bits are fixed for the version and variant markers, leaving 122 bits of pure randomness:

550e8400-e29b-41d4-a716-446655440000
             ^    ^
        version 4  variant

Because the value is random rather than coordinated, there is no central registry guaranteeing no two are ever equal. Two independent generators could, in principle, produce the same 122 random bits. "Universally unique" is a statistical promise, not an absolute one — but the numbers behind that promise are staggering.

The Birthday Problem, Applied to UUIDs

The intuitive mistake is to ask, "What is the chance a new UUID matches one specific existing UUID?" That probability is astronomically small: 1 in 2^122. But collisions are not about matching one specific value — they are about any two values in a set matching. That is the birthday problem.

The birthday problem is why a room of just 23 people has a ~50% chance that two share a birthday, even though there are 365 days. Pairs grow quadratically with the number of items, so the odds rise far faster than intuition suggests.

For a keyspace of size N, the approximate number of items n needed for a 50% collision chance is:

n ≈ 1.1774 × sqrt(N)

For UUID v4, N = 2^122, so:

n ≈ 1.1774 × sqrt(2^122) ≈ 2.71 × 10^18

That is the 2.7 quintillion figure. Even generating a trillion UUIDs, the probability of a single collision is on the order of 10^-15 — far less likely than your server being hit by a meteor during the request.

Putting the Numbers in Perspective

Concrete scale helps. Suppose you generate UUIDs at different rates and ask how long until a 50/50 collision becomes likely:

Only at a sustained trillion per second — far beyond what any normal system produces — does the timeframe shrink to something a human would notice. For ordinary applications generating millions or even billions of IDs over their lifetime, the collision probability rounds to zero.

When UUID Collisions Actually Happen

In practice, the rare real-world duplicates are almost never caused by the birthday math. They come from broken assumptions:

1. A weak or non-cryptographic random source

UUID v4's guarantees assume a cryptographically secure random number generator (CSPRNG). If a library falls back to a fast but predictable PRNG (like a seeded Math.random() style generator), the effective entropy can be far below 122 bits, dramatically raising collision odds. Always use a proper source such as crypto.randomUUID() in browsers and Node, or your language's secure UUID library.

2. Reused or fixed seeds

Seeding a PRNG with a constant, the process ID, or the current second means multiple processes can produce identical sequences. Containers that all start at the same moment from the same image are a classic offender. A CSPRNG avoids this because it draws from the operating system's entropy pool.

3. Deterministic versions used by mistake

UUID v3 and v5 are designed to collide for identical inputs — the same namespace and name always produce the same UUID. That is a feature for deduplication, but if you expected randomness, it looks like a collision. See the UUID versions explained guide for when each version is appropriate.

4. Truncation

Storing only the first 8 or 12 characters of a UUID to "save space" throws away most of the entropy and turns an astronomically safe ID into a collision-prone one. Never truncate a UUID and still treat it as unique.

How Other ID Formats Compare

Collision resistance scales with entropy, so different formats trade size for safety:

• UUID v7 keeps 74 random bits plus a 48-bit timestamp. The timestamp partitions the keyspace by millisecond, so collisions only need to be avoided within the same millisecond — making real-world collisions even less likely than the raw random-bit count suggests. Generate them with the UUID v7 Generator.
• ULID uses 80 random bits plus a timestamp, so it is comparably safe. See UUID v7 vs ULID for the full comparison.
• Nano ID lets you tune length and alphabet; the default 21-character ID has ~126 bits of entropy, on par with a UUID. Shorter Nano IDs trade entropy for compactness, so size them deliberately. The UUID alternatives guide covers the trade-offs.

Practical Guidance

To keep collisions firmly in the realm of theory:

1. Use a CSPRNG-backed generator. Prefer built-ins like crypto.randomUUID() or a maintained UUID library over hand-rolled randomness.
2. Do not seed manually. Let the OS entropy pool do its job, especially in containers and serverless functions that start in bursts.
3. Never truncate a UUID you intend to treat as unique.
4. Add a database unique constraint on UUID primary keys. It costs almost nothing and turns a one-in-a-quintillion event into a caught, retryable error instead of silent data corruption.
5. Pick the right version. Use v4 for random opaque IDs, v7 for sortable database keys, and reserve v3/v5 for deliberate deterministic IDs.

With those habits, the probability of a UUID collision affecting your system is so small that it is not worth a second thought.

FAQ

Can two UUIDs ever be the same?

Theoretically yes — UUIDs are random, not centrally coordinated, so identical values are not mathematically impossible. In practice, the odds for properly generated version-4 UUIDs are so small (a 50% chance only after ~2.71 × 10^18 IDs) that collisions effectively never occur. Generate them safely with the UUID v4 Generator.

How many UUIDs can I generate before a collision is likely?

You would need roughly 2.71 quintillion (2.71 × 10^18) version-4 UUIDs for a 50% chance of a single collision. To put it differently, generating a billion UUIDs per second, you would wait about 86 years to reach even odds. Most applications never generate more than a few billion in their entire lifetime.

Are UUID v4 collisions more likely than v7 collisions?

They are comparably negligible, but they differ in mechanism. UUID v4 relies entirely on its 122 random bits. UUID v7 adds a 48-bit millisecond timestamp, so collisions only need to be avoided among IDs created in the same millisecond — which, combined with 74 random bits, makes real-world collisions even less likely. Try the UUID v7 Generator to see them.

What is the most common cause of real UUID collisions?

Almost always a faulty random source: a non-cryptographic PRNG, a fixed or reused seed (common when many containers start simultaneously), or accidental truncation of the UUID. The birthday math is essentially never the culprit. Using a CSPRNG-backed generator eliminates the practical risk.

Should I still add a unique constraint if collisions are so unlikely?

Yes. A unique index on your UUID column is cheap insurance: it converts a theoretically possible (and bug-induced) duplicate into a clear, catchable error rather than silent data corruption. It is a best practice regardless of how unlikely a collision is.

Does using uppercase or formatted UUIDs change collision odds?

No. Formatting changes (uppercase vs lowercase, braces, URN prefix, removing hyphens) only affect the string representation, not the 122 bits of underlying randomness. The collision probability is identical regardless of how you display the value.

Want IDs you can trust? Generate cryptographically random identifiers with the UUID Generator or UUID v4 Generator, and use the built-in UUID Decoder to inspect any UUID's version and structure.