Every UUID Version Explained: v1 through v8, Nil, and Max

Most developers reach for uuid.v4() and never think about it again. That works for 80% of cases — but there are nine defined UUID versions, each designed for a different trade-off. RFC 9562 (May 2024) standardized three new ones on top of the original RFC 4122 five. This post walks through all of them.

Every UUID is 128 bits, regardless of version. The version nibble (the first character of the 3rd group — the M in xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx) identifies which version you're looking at.

v1 — Timestamp + Node

f81d4fae-7dec-11d0-a765-00a0c91e6bf6

The original time-based UUID. Combines a 60-bit timestamp (100-ns intervals since October 15, 1582 — the Gregorian calendar epoch) with a 48-bit node identifier and a 14-bit clock sequence.

The node traditionally held the machine's MAC address, which made v1 UUIDs privacy leaks. Modern libraries use a random node value with the multicast bit set to signal "this is not a real MAC." Unfortunately v1's byte layout scatters timestamp bits across the UUID, so v1 UUIDs do not sort by creation time.

Use it when: you need backward compatibility with legacy systems. For new code, use v6 or v7 instead.

v2 — DCE Security

000004d2-e2f3-21ee-b962-0242ac120002

A niche variant from the Distributed Computing Environment. It replaces part of a v1 timestamp with a POSIX user ID or group ID. Almost no modern system uses v2 — most UUID libraries don't even implement it.

Use it when: never, for practical purposes.

v3 — MD5 Namespace Hash

9073926b-929f-31c2-abc9-fad77ae3e8eb

Deterministic UUIDs: same inputs always produce the same UUID. v3 hashes a namespace UUID plus a name string using MD5, then stamps the version bits on top.

The four standard namespaces (DNS, URL, OID, X.500) are defined in RFC 4122 Appendix C. Use them so your UUIDs interoperate with other systems hashing the same names.

Use it when: you need reproducible IDs from a name (e.g., "what UUID should this URL always have?"). For new code, prefer v5 — same idea, stronger hash.

v4 — Random

550e8400-e29b-41d4-a716-446655440000

The most popular UUID version. 122 bits of cryptographic randomness plus 6 fixed bits for version and variant. Every bit except those fixed 6 is drawn from a CSPRNG.

Collision probability is astronomical: you'd need to generate roughly 2.7 × 10¹⁸ UUIDs to hit a 50% chance of a single duplicate. Simple, universal, no external inputs required.

Use it when: any general-purpose ID where you don't need sortability and don't want creation time exposed.

v5 — SHA-1 Namespace Hash

74738ff5-5367-5958-9aee-98fffdcd1876

Identical concept to v3 but uses SHA-1 instead of MD5. Same namespace mechanism, stronger hash algorithm. If you need deterministic UUIDs in new code, this is the right pick.

Use it when: you're generating deterministic IDs from known inputs like URLs, DNS names, or domain-specific identifiers.

v6 — Reordered v1 (Sortable)

1ee23a80-0b01-68b9-a962-0242ac120002

Added in RFC 9562 as a fix for v1's sort ordering. Takes the same 60-bit Gregorian timestamp and node/clock fields, but places the most-significant timestamp bits at the start of the UUID. Result: lexicographic sorting matches creation time.

v6 preserves v1's structure (node field, clock sequence), which matters if you're migrating a legacy v1 system and want the same semantics with proper ordering. For brand-new code, v7 is simpler.

Use it when: replacing v1 IDs in an existing system that needs the node and clock sequence semantics.

v7 — Unix Timestamp + Random (The Modern Default)

0191a1c0-7d54-7b8f-9c2d-3e4f56789abc

The new recommended default for database primary keys. First 48 bits are milliseconds since Unix epoch. Remaining 74 bits are random (minus version and variant). Because the timestamp is leading, v7 sorts naturally by creation time in both binary and string form.

This is a huge win for B-tree indexes: new inserts always go to the rightmost leaf, same performance as a BIGINT auto-increment. No more page splits, no more index bloat.

Use it when: database primary keys, event logs, anywhere you want sortable globally-unique IDs without needing a coordinator.

v8 — Custom / Vendor

A deliberate escape hatch in RFC 9562. v8 lets you pack your own application-specific data into a UUID-shaped 128-bit value while still being recognizable as a UUID.

Common uses: encoding a shard key plus a local ID, embedding a domain-specific timestamp scheme, or combining multiple identifier types. The only requirement: set the version nibble to 8 and the variant bits to 10. Everything else is up to you.

Use it when: none of v4/v5/v7 fit your layout needs — and document the format clearly so future developers understand it.

Nil UUID — All Zeros

00000000-0000-0000-0000-000000000000

A reserved sentinel representing "no value" or "unset." Useful as a default value, a placeholder, or to represent absence in systems that require a non-null UUID field.

Use it when: you need an explicit "empty" UUID. Never generate it randomly.

Max UUID — All Ones

ffffffff-ffff-ffff-ffff-ffffffffffff

Added in RFC 9562 as the counterpart to Nil. Represents the maximum possible UUID value. Useful as a sentinel for "greatest value" in sorted collections and boundary markers.

Quick decision table

Try them all

You can generate any of these versions in our free UUID Generator. It supports all nine variants, has a built-in inspector that decodes any UUID you paste into it, and runs entirely in your browser.

For the detailed spec, see RFC 9562.