RFC 4122 Explained
RFC 4122 is the IETF standard, published in 2005, that defines exactly how a UUID is structured, generated, and interpreted. It's why a UUID generated by one system can be safely understood by any other.
What the standard actually specifies
RFC 4122 defines three things:
- Layout - a 128-bit value split into fields:
time_low,time_mid,time_hi_and_version,clock_seq_hi_and_reserved,clock_seq_low, and a 48-bitnodefield, rendered as the familiar8-4-4-4-12hex string. - Version - 4 bits indicating how the UUID was generated (time-based, random, name-based, etc).
- Variant - a couple of reserved bits identifying the UUID as RFC-compliant (as opposed to legacy/reserved layouts from older systems).
The version bit, visually
The version number is always encoded in the first hex digit of the third group:
3fa85f64-5717-4562-b3fc-2c963f66afa6
^
version 4
The five original versions (RFC 4122)
| Version | Based on | Typical use |
|---|---|---|
| v1 | Timestamp + MAC address | Legacy systems; leaks host MAC, rarely used today |
| v2 | DCE Security (timestamp + POSIX UID/GID) | Essentially unused in practice |
| v3 | MD5 hash of a namespace + name | Deterministic IDs from a name (e.g. Minecraft offline-mode UUIDs) |
| v4 | Random | The default choice for most applications today |
| v5 | SHA-1 hash of a namespace + name | Like v3 but with a stronger hash |
RFC 9562: the 2024 update
In May 2024, RFC 9562 officially obsoleted RFC 4122 and added three new versions:
| Version | Based on | Why it was added |
|---|---|---|
| v6 | Reordered timestamp + random, for sortability | A v1 replacement that sorts correctly as a string |
| v7 | Unix epoch milliseconds + random | The modern recommendation for sortable database keys - see UUID v4 vs v7 |
| v8 | Custom / vendor-defined | An escape hatch for application-specific UUID layouts |
RFC 9562 also formally defines the all-zero nil UUID (00000000-0000-0000-0000-000000000000) and an all-F max UUID (ffffffff-ffff-ffff-ffff-ffffffffffff) as reserved sentinel values.
Why this matters in practice
Because every major language and database follows this standard, a UUID generated in Python with uuid.uuid4() can be stored in a SQL Server UNIQUEIDENTIFIER column, read back in Java as a java.util.UUID, and rendered correctly by this site's UUID generator - all without any data loss or ambiguity.