UUID Collision Probability: Can Two UUIDs Be the Same?

The Birthday Problem

The intuition comes from a classic puzzle: in a group of just 23 people, there's about a 50% chance two share a birthday. Collisions become likely much sooner than people expect, because every new item can collide with any previous one.

For UUIDs, the probability of at least one collision among n random UUIDs is approximately:

p ≈ n² ÷ (2 × 2^122)

That formula is accurate when p is small. Solving for different probabilities gives the numbers below.

To put the last row in context: generating a billion UUIDs every second, it would take around 85 years to reach 2.7 quintillion.

Why Real Duplicates Still Happen

When teams do find duplicate UUIDs, the cause is almost never bad luck. Common culprits:

Weak or Broken Randomness

• Generators using Math.random() or another non-cryptographic generator with limited internal state.
• Virtual machines or containers cloned with identical random generator state.
• Embedded devices with poor entropy at boot.
• Libraries that seed a generator with the current time, so two processes started together produce the same sequence.

Application Bugs

• An ID generated once and reused for many records, such as a default value evaluated at startup.
• Copying records and their IDs between environments.
• Retrying an insert with the same ID after a partial failure, which is fine if intended (idempotency) but surprising if not.
• Truncating UUIDs, for example storing only the first 8 characters to save space, which dramatically reduces uniqueness.

Non-Random Versions

Versions 1, 6 and 7 include timestamps and either node identifiers or random data. Version 7 still has 74 bits of randomness or counter data per millisecond, which is ample in practice, but a broken clock or a poor implementation can increase risk. Name-based versions 3 and 5 are deterministic by design: the same namespace and name always produce the same UUID, which is a feature, not a collision.

Practical Safeguards

Even though collisions are vanishingly rare with good generators, sensible systems:

• Use a unique constraint on UUID columns. If a duplicate ever appears, it fails loudly instead of corrupting data.
• Use platform generators: crypto.randomUUID(), uuid.uuid4(), UUID.randomUUID(), Guid.NewGuid(), or database functions.
• Never truncate UUIDs for uniqueness-critical uses.
• Don't treat UUIDs as secrets. Uniqueness isn't the same as unguessability; use dedicated token generators for security.

What is UUID v4 explains how proper generation works, and UUID v4 vs UUID v7 discusses what changes when part of the ID is a timestamp.

Generating With a Secure Source

The UUID v4 generator uses your browser's Web Crypto API, the same cryptographically secure source browsers use for security features, to generate random version 4 UUIDs, one at a time or in batches of up to 1,000. If you're checking IDs from another system, the UUID validator shows whether each value is well-formed and which version it claims to be.

What About Shorter IDs?

Many systems shorten UUIDs for URLs or display, for example by taking the first 8 characters. That changes the maths dramatically:

An 8-character prefix collides quickly in any busy system. If you need short public IDs, use a dedicated scheme with enough random bits and a uniqueness check, not a truncated UUID.

Collisions Across Systems

When merging datasets from different systems, collisions between correctly generated v4 UUIDs remain negligible. Duplicates found during merges usually mean the same record was copied into both systems, which is a data question, not a UUID one.

Summary

UUID v4 collisions require around 2.7 quintillion values for even odds. In practice, duplicates come from weak randomness or bugs, so use platform generators, keep unique constraints, and never truncate.