What Is a UUID, and Is It Really Unique?
A UUID, or Universally Unique Identifier, is a 16-octet (128-bit) identifier whose version and variant bits define how the remaining fields are interpreted.
A worked example with numbers
Suppose a service generates 1 billion version-4 UUIDs. With N = 1,000,000,000 draws from M = 2^122 possible random values, the birthday approximation N²/(2M) is about 9.4 × 10^-20 for at least one collision when the generator is sound. That tiny number is not zero: a database can still enforce a unique column and retry on the rare conflict. The UUID generator supplies a formatted value, not proof that a different system never issued it.
How to set the rule before the result
Use a UUID when a system needs a broadly unique identifier without a central sequential counter. Store the full canonical string or 16 bytes consistently, identify the version, and use a database uniqueness constraint if the identifier is a key. Choose a cryptographic random source for v4; a visually random string made from a weak source is not the same construction.
Common mistakes that change the odds or the process
Do not call a UUID secret merely because it looks long. Do not truncate it and retain the same collision estimate: fewer retained bits mean fewer possible values. Do not treat a UUID as an authenticated user identity, timestamp, permission, or checksum. Do not assume different text encodings of a UUID are interchangeable without a documented parser.
Where this method stops being appropriate
UUIDs are useful identifiers, not access tokens or personal-data protection. A collision calculation assumes independent, well-distributed values and does not protect a database from a broken generator, malicious input, inconsistent normalization, or a missing unique constraint.
How the random source fits into the rule
IETF RFC 9562 specifies that UUIDs contain 16 octets and defines version 4 as randomly or pseudorandomly generated. The RFC’s format explains the 122 random v4 bits; the collision approximation is a model for that defined finite space, not a promise that an application can skip validation.
Check the actual population and denominator
Suppose a service generates 1 billion version-4 UUIDs. With N = 1,000,000,000 draws from M = 2^122 possible random values, the birthday approximation N²/(2M) is about 9.4 × 10^-20 for at least one collision when the generator is sound. That tiny number is not zero: a database can still enforce a unique column and retry on the rare conflict. The UUID generator supplies a formatted value, not proof that a different system never issued it.
Set the rule before an output exists
Use a UUID when a system needs a broadly unique identifier without a central sequential counter. Store the full canonical string or 16 bytes consistently, identify the version, and use a database uniqueness constraint if the identifier is a key. Choose a cryptographic random source for v4; a visually random string made from a weak source is not the same construction.
Keep a different process from slipping in
Do not call a UUID secret merely because it looks long. Do not truncate it and retain the same collision estimate: fewer retained bits mean fewer possible values. Do not treat a UUID as an authenticated user identity, timestamp, permission, or checksum. Do not assume different text encodings of a UUID are interchangeable without a documented parser.
Limit the conclusion to this stated case
UUIDs are useful identifiers, not access tokens or personal-data protection. A collision calculation assumes independent, well-distributed values and does not protect a database from a broken generator, malicious input, inconsistent normalization, or a missing unique constraint.
Name the source behind the numerical claim
IETF RFC 9562 specifies that UUIDs contain 16 octets and defines version 4 as randomly or pseudorandomly generated. The RFC’s format explains the 122 random v4 bits; the collision approximation is a model for that defined finite space, not a promise that an application can skip validation.
Read the v4 bit budget correctly
| UUID v4 component | Bits | Role |
|---|---|---|
| Total UUID format | 128 | Stored identifier size |
| Version and variant | 6 | Fixed format markers |
| Random payload | 122 | Collision-resistant value space |
The 122-bit payload gives 2^122 possible v4 random values, not 2^128 independently random choices. A database constraint remains useful because a format-level probability statement does not check an arriving duplicate.
Plan for the rare conflict anyway
On insertion, reject or retry a UUID that already exists under the same canonical representation. This is ordinary defensive design, not evidence that UUIDs are unreliable. It also catches non-random causes of duplicates, such as a faulty generator, a copied test value, or an import that reused identifiers.
Keep identity and identification separate
A UUID can identify a row after a system has authenticated a user, but possession of an identifier alone does not prove who made a request. Treat it as an address for data, not as a credential. When identifiers appear in URLs or logs, apply normal access checks and privacy review. The large v4 space reduces accidental collision risk; it does not authorize whoever can copy a visible string.