UUIDTools.comThe version is the 13th hex digit of a UUID (the M in xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). RFC 9562 defines versions 1 through 8 plus two special values. Newer is not automatically better: each version solves a different problem.
Comparison
| Version | Based on | Sortable | Leaks time? | Best for |
|---|---|---|---|---|
| v1 | Gregorian time + node | No | Yes (+ node) | Legacy systems |
| v2 | DCE Security | No | Partly | Almost nothing |
| v3 | MD5(namespace + name) | No | No | Legacy deterministic IDs |
| v4 | Random | No | No | General-purpose IDs |
| v5 | SHA-1(namespace + name) | No | No | Deterministic IDs |
| v6 | Reordered v1 time + node | Yes | Yes | Migrating from v1 |
| v7 | Unix ms time + random | Yes | Yes | Database primary keys |
| v8 | Your own layout | Your choice | Your choice | Custom formats |
| Nil | All zeros | n/a | No | "No UUID" placeholder |
| Max | All ones | n/a | No | Sentinel / upper bound |
UUID v4 vs v7
Choose v4 when you need an unpredictable identifier that reveals nothing. Choose v7 when UUIDs are database keys or event IDs and chronological order helps: v7 starts with a 48-bit millisecond timestamp, so inserts append to the end of an index instead of landing at random positions. v4 has 122 random bits; v7 has 74 random bits plus the timestamp.
Version 1: time and node
60-bit timestamp in 100-nanosecond intervals since 15 October 1582, a 14-bit clock sequence, and a 48-bit node (traditionally the MAC address). The timestamp bits are stored low-to-high, so v1 does not sort by time. Because it can expose a MAC address, our generator uses a random multicast node. Generate v1.
time_low (32) | time_mid (16) | 0001 + time_high (16) | variant + clock_seq (16) | node (48)
Version 2: DCE Security
Version 1 with the low timestamp bits replaced by a local identifier (such as a POSIX UID) and a domain. Defined by DCE 1.1, only reserved by RFC 9562, and very rarely used. Generate v2.
Versions 3 and 5: names and hashes
Hash a namespace UUID plus a name (MD5 for v3, SHA-1 for v5) and stamp in the version and variant bits. The same input always yields the same UUID, which makes them ideal for stable IDs derived from URLs, domains or natural keys. Always hash the name as UTF-8 for cross-language compatibility. Prefer v5 over v3. v3 · v5.
Version 4: random
122 random bits. No structure, no information. Generate v4.
random (48) | 0100 + random (12) | variant + random (62)
Version 6: sortable v1
The same timestamp, clock sequence and node as v1 with the timestamp bits reordered most-significant first so UUIDs sort by creation time. Intended as a bridge for existing v1 users. Generate v6.
time_high (32) | time_mid (16) | 0110 + time_low (16) | variant + clock_seq (16) | node (48)
Version 7: Unix time and random
The recommended time-ordered UUID. 48-bit Unix timestamp in milliseconds, then random bits. Implementations keep UUIDs generated in the same millisecond monotonic. Generate v7.
unix_ts_ms (48) | 0111 + rand_a (12) | variant + rand_b (62)
Version 8: custom
Only the version and variant bits are fixed; the other 122 bits are yours. Useful for embedding shard IDs or for hashing names with SHA-256. Do not expect other systems to understand your layout. Generate v8.
Nil and Max
The Nil UUID 00000000-0000-0000-0000-000000000000 and the Max UUID ffffffff-ffff-ffff-ffff-ffffffffffff are special constants. Nil · Max.
The variant
The top bits of the 17th hex digit say which UUID family the value belongs to. Every UUID described here uses the 10xx variant (digit 8, 9, a or b). Other variants are reserved for legacy NCS and Microsoft GUIDs. See the decoder to inspect any UUID.