UUID v4 Collision Probability — Is a UUID Really Unique?

UUID v4 collisions are theoretically possible but practically impossible at any realistic scale. The format gives you 122 bits of randomness — 5.3 undecillion unique values — and the math works out to about a 50% collision chance only after generating 2.7 quintillion UUIDs. Here is exactly what the numbers mean and when you should care.

The Math Behind UUID v4 Uniqueness

A UUID v4 looks like this: 550e8400-e29b-41d4-a716-446655440000

128 total bits, but 6 bits are fixed version/variant markers, leaving 122 random bits. That gives:

• 2¹²² = 5,316,911,983,139,663,491,615,228,241,121,378,304 possible values
• Roughly 5.3 undecillion (5.3 × 10³⁶)

The birthday paradox formula for the number of UUIDs needed to reach a 50% collision probability:

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

At 1 billion UUIDs generated per second, reaching that number would take 86 years. No application ever comes close.

UUIDs Generated	Collision Probability
1,000	1 in 1027 (unmeasurably small)
1 million	1 in 1021
1 billion	1 in 1015
1 trillion	1 in 109 (1 in a billion)
2.71 quintillion	~50% (birthday paradox threshold)

The Real Risk: Bad Random Number Generators

The birthday paradox math assumes truly random bits. If your random number generator is weak, predictable, or seeded with low-entropy values, collisions become far more likely — and the issue is not the UUID format itself, it is the generator.

What makes a UUID generator safe:

• Cryptographically secure random source — uses OS-level entropy (/dev/urandom on Linux/Mac, CryptGenRandom on Windows). In browsers, secure random generator. These are the sources all major UUID libraries use.
• Not seeded with timestamp only — early UUID v4 implementations in some languages seeded with the current time, which produces predictable values. This was a real bug in some PHP versions.
• Not re-using seeds — VMs that clone their state (snapshots, containers) can end up with identical random seeds across instances. This is why some cloud providers randomize entropy pools on boot.

Safe generators (crypto-secure):

Python:   uuid.uuid4()  # uses os.urandom()
Node.js:  crypto.randomUUID()  # built-in, crypto-secure
Browser:  crypto.randomUUID()  # available in modern browsers
Go:       google/uuid  # reads from crypto/rand

Sell Custom Apparel — We Handle Printing & Free Shipping

UUID Collision vs. Hash Collision — Different Problems

UUID collision and hash collision are often confused but they are completely different scenarios.

UUID collision means two independently generated UUIDs happen to be identical. With v4, this requires both generators to randomly pick the same 122-bit value. Probability: astronomically small.

Hash collision (relevant to UUID v3 and v5, which use MD5 and SHA-1) means two different inputs produce the same UUID output. These versions are deterministic — same input always produces the same UUID. The collision concern is about whether two different strings could map to the same UUID, which is the hash collision problem and is more relevant for cryptographic attack scenarios than accidental collisions.

For most developers generating IDs for database records, v4 is the right choice. It is random, it is fast, and the collision risk is not worth thinking about at any realistic application scale.

Practical Takeaways for Developers

Here is what the collision math actually means for your application:

• At 10,000 records — collision probability is so small it cannot be expressed as a meaningful fraction. Do not add collision checking logic.
• At 100 million records — still negligible. Adding a UNIQUE constraint on your UUID column is good practice for data integrity, not collision prevention.
• At 1 trillion records — collision probability is roughly 1 in a billion per insert. A UNIQUE constraint will catch it.
• Always use a UNIQUE constraint — not because collisions are likely, but because database constraints are your safety net for any ID-uniqueness guarantee regardless of the source.
• Use crypto-secure generation — uuid.uuid4(), crypto.randomUUID(), or any UUID library that explicitly uses OS entropy. Avoid rolling your own.

Need a UUID right now? The WildandFree UUID Generator uses crypto.randomUUID() in your browser — fully crypto-secure, no server involved.

Frequently Asked Questions

Can two UUIDs ever be the same?

Mathematically yes, practically no. UUID v4 has 122 random bits. The probability of any two independently generated UUIDs being identical is roughly 1 in 5.3 undecillion. You would need to generate trillions of UUIDs before the risk becomes measurable.

Should I check for UUID collisions in my database?

Add a UNIQUE constraint on your UUID column as standard database hygiene, but do not write application-level collision detection logic. The constraint will catch any duplicate (from any source) while adding negligible overhead. At realistic data volumes, the constraint will never fire due to a true UUID collision.

Are UUID v7 collisions less likely than UUID v4?

They are essentially the same. UUID v7 uses a timestamp prefix plus random bits. The timestamp reduces the total random space slightly, but the remaining random bits still make collisions effectively impossible at any real scale. The timestamp component improves database insert performance (sequential ordering), not uniqueness.

What if my random number generator is broken?

If your language runtime or OS random source has a bug, UUID uniqueness breaks down completely — all generated UUIDs could be identical. This happened in real systems (PHP in early versions, some Java VMs in VMs after cloning). Always use your language's crypto-secure UUID library rather than building your own generator.