UUID Collision

Definition

A UUID collision occurs when two independently generated UUIDs have the same value. Because a UUID is supposed to be unique, a collision would mean two different records or objects are assigned the same identifier — a data integrity failure.

The design of UUID v4 makes collisions so improbable that they are treated as impossible in practice. However, “impossible in practice” is not the same as “mathematically impossible” — understanding the actual probability helps you apply the right tool for the right job.

The birthday problem

UUID collision probability follows the birthday problem: the chance that any two values in a set are equal, given a fixed pool size.

UUID v4 has 122 bits of randomness (128 bits minus 6 bits used for version and variant). This gives a pool of 2¹²² possible values, approximately 5.3 × 10³⁶.

The probability that at least one collision exists among n generated UUIDs is approximately:

P(collision) ≈ 1 - e^(-n²/2N)

Where N = 2¹²² (the pool size).

Collision thresholds for UUID v4

For context: generating 1 billion UUIDs per second continuously would take 85 years to reach 2.7 × 10¹⁸. No real system approaches this rate.

UUID v7 collision risk

UUID v7 uses a 48-bit millisecond timestamp prefix followed by 74 bits of randomness (with 4 bits for version and 2 for variant). Within a single millisecond, the collision probability is governed by those 74 random bits.

Within one millisecond, 74 bits provides a pool of ~1.9 × 10²² values. You would need to generate more than 100 billion UUIDs in a single millisecond before a collision became meaningful — well beyond any hardware capability.

Additionally, UUID v7 implementations typically use a per-millisecond monotonic counter (as recommended by RFC 9562 §6.2), which eliminates same-millisecond collisions entirely within a single generator instance.

When collisions are not acceptable

The probabilistic uniqueness of UUIDs is sufficient for:

• Database primary keys
• Distributed system identifiers
• Event IDs and trace IDs
• Idempotency keys

It is not sufficient when:

• The ID must be unguessable (security token) — use a purpose-built CSPRNG token, not a UUID
• The ID is used for deduplication where a false positive has serious consequences — add a uniqueness constraint in the database and handle the rare constraint violation

A database unique constraint is the recommended defense. If a collision did occur (probability: essentially zero), the constraint violation would surface it immediately rather than silently corrupting data.

Entropy and the CSPRNG

UUID v4 randomness comes from a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

• Browsers: crypto.getRandomValues()
• Node.js: crypto.randomFillSync() / crypto.randomUUID()
• Python: os.urandom() (used internally by the uuid module)
• Go: crypto/rand

A weak or predictable random source (such as Math.random()) dramatically reduces effective entropy and makes collisions and prediction attacks much more likely. Always use a CSPRNG-backed UUID library.

Related terms

• Entropy — the randomness that makes collisions negligible
• UUID — the full definition and format
• Variant — the bits that distinguish RFC 9562 UUIDs

Generate collision-safe UUIDs with the UUID v4 generator or UUID v7 generator.