In this article
Developers use UUIDs because they can create an ID on any machine without asking a central database whether it is taken. That only works if two machines never pick the same one. Is that a promise, a hope or a statistic?
What is inside a UUID
A UUID is 128 bits. In version 4, six of those bits are fixed to say “I am version 4” and “I follow the standard layout”. The other 122 are random. That is where the huge number comes from.
- Random bits122
- Version marker4
- Variant marker2
Each dot is one bit. Only the six at the end are not random.
The odds of a collision
This is the birthday problem again: collisions appear much sooner than you would think, but not nearly soon enough to matter at normal sizes. The chance that any two among n random UUIDs match is about n² divided by twice the number of possible values.
| UUIDs generated | Chance of any duplicate | In words |
|---|---|---|
| 1 billion (10⁹) | 9.4 × 10⁻²⁰ | about 1 in 10 quintillion |
| 1 trillion (10¹²) | 9.4 × 10⁻¹⁴ | about 1 in 10 trillion |
| 1 quadrillion (10¹⁵) | 9.4 × 10⁻⁸ | about 1 in 10 million |
| 1 quintillion (10¹⁸) | about 9.4% | about 1 in 11 |
| 2.7 quintillion | 50% | a coin flip |
The 6-from-49 lottery jackpot is about 1 in 14 million. A trillion UUIDs is roughly 700,000 times less likely to clash than that.
You would run out of disk space long before you ran out of luck.
Where collisions actually come from
- A weak random generator. Old or badly seeded generators repeat. The maths above only holds for a good cryptographic source.
- Cloned machines. Two virtual machines started from the same snapshot may share a seed.
- Copy and paste. The most common “collision” is somebody pasting the same ID twice.
- Truncating. Cutting a UUID to 8 characters leaves 32 bits, and collisions then appear at tens of thousands of IDs.
- About 77,000 IDs for a 50% clash
- Fine for a small demo, risky at scale
- About 2.7 quintillion IDs for a 50% clash
- Safe at any realistic size
Length is what protects you. See the same idea for passwords in password entropy.
Which version should you use?
- v1Time and machineBuilt from the clock and the network address. Unique, but it can reveal when and where it was made.
- v4Fully randomThe usual choice. No information leaks, but IDs have no order, which can slow some databases.
- v7Time-orderedA timestamp followed by random bits. Newer IDs sort after older ones, which is kinder to database indexes. Defined in RFC 9562 (2024).
For database primary keys, v7 is increasingly popular. For a plain unique ID, v4 is still fine.
A hash is a different tool altogether: it summarises content rather than naming it. See what a hash is.
Questions people ask
Can two UUIDs be the same?
In theory yes, in practice almost never. A version 4 UUID has 122 random bits, so you would need about 2.7 quintillion of them for a 50 percent chance of a single duplicate.
What is the probability of a UUID v4 collision?
About 1 in 10 quintillion after generating a billion UUIDs, and about 1 in 10 trillion after a trillion. The chance rises with the square of how many you generate.
Is UUID v4 or v7 better?
v4 is fully random and fine for most uses. v7 puts a timestamp first so IDs sort by time, which helps database indexes. For primary keys, v7 is often preferred.
Is a UUID the same as a GUID?
In practice yes. GUID is Microsoft's name for the same 128-bit identifier format.
Are UUIDs secure to use as secrets?
Not by themselves. Random v4 UUIDs are hard to guess, but they were designed to be unique, not secret. Use a dedicated cryptographic token for secrets.