UUID Versions 1–8 Explained

Start with the shared 128-bit format

RFC 9562 defines a UUID as 16 octets, or 128 bits. The familiar text form contains 32 hexadecimal digits in five groups separated by four hyphens:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

M = four-bit version field
N = hexadecimal digit containing the leading variant bits

The version occupies bits 48 through 51, which appear as the first hexadecimal digit of the third group in standard text. Under the variant defined by RFC 9562, bits 64 and 65 are 10, so the first hexadecimal digit of the fourth group is 8, 9, a, or b. Those fixed fields consume six bits; each version assigns the other 122 bits differently.

Hexadecimal case is not semantic. A normalized lowercase string and an uppercase string can represent the same 128-bit value. Hyphens are presentation, while the bit positions determine the format. Raw binary interchange requires extra care because Microsoft COM GUID serialization has a historical byte-order caveat that text often hides.

Variant and version answer different questions

The variant chooses the broad layout family. RFC 9562 preserves older and vendor-specific variant ranges for compatibility: an NCS-reserved range, the variant defined by the RFC, a Microsoft-reserved range, and a future-reserved range. The interpretation of every other bit depends on this first classification.

The version is a four-bit subtype within the RFC variant. It identifies layouts 1 through 8, while values 9 through 15 remain reserved for future definitions. A parser should therefore identify the variant before presenting a version-specific interpretation. Merely seeing 4 in the third group does not prove that an arbitrary 128-bit string is a compliant UUIDv4.

UUID versions at a glance

UUIDv1: Gregorian time, clock sequence, and node

UUIDv1 contains a 60-bit count of 100-nanosecond intervals since 00:00:00 UTC on October 15, 1582. A 14-bit clock sequence helps avoid duplicates when the clock moves backward or the node identifier changes. The last 48 bits hold a spatially unique node identifier, traditionally an IEEE 802 MAC address but optionally a properly marked random value.

The timestamp is split across fields in an order inherited from the original format, so raw byte sorting does not place the most significant time bits first. That awkward ordering and the uncommon Gregorian epoch are two reasons RFC 9562 introduced newer time layouts.

Privacy is the major operational concern. A hardware MAC address can expose a network-interface identifier and potentially its manufacturer. RFC 9562 advises against embedding MAC addresses and describes randomized node identifiers instead. Even with a randomized node, the timestamp remains visible and can reveal approximately when an object was created.

UUIDv2: reserved, but outside RFC 9562

Version 2 is assigned to DCE Security UUIDs with embedded POSIX identifiers. RFC 9562 deliberately does not define that format; it points to external DCE specifications and leaves the details out of scope. The version table therefore records the reservation without providing an interoperable generation algorithm.

A generic UUID validator can recognize a version nibble of 2, but that observation cannot verify DCE Security fields or semantics. Avoid inventing field positions, truncation rules, or security properties. If a legacy environment truly requires v2, use its authoritative platform specification and implementation.

UUIDv3 and UUIDv5: deterministic namespace names

Name-based UUIDs map a namespace ID plus a canonical byte representation of a name to the same UUID every time. Version 3 uses MD5; version 5 uses SHA-1. RFC 9562 says v5 should be used instead of v3 where possible. Both algorithms place hash output into the UUID and then overwrite the required version and variant bits.

UUIDv5(namespace_uuid, canonical_name_bytes)

same namespace + same bytes  → same UUID
different namespace or bytes → generally different UUID

Canonicalization is part of the contract. The text Example.com, example.com, a Unicode normalization difference, or a different character encoding can produce a different result unless the namespace's rules normalize them first. Store or document the exact namespace UUID, encoding, normalization, and case policy.

Version 5's use of SHA-1 does not make a UUID a digital signature, authenticated identifier, or secure password hash. It is a deterministic identifier construction with only 122 effective output bits after the fixed fields. RFC 9562 directs schemes that need SHA-256 or a newer hash to define a compatible UUIDv8 construction rather than labeling it v5.

UUIDv4: 122 random bits

UUIDv4 fills the non-fixed fields with truly random or pseudorandom data. After four version bits and two variant bits are set, 122 random bits remain. It needs no clock, node address, namespace, or central allocator, which makes it the broadly supported general-purpose choice for independently generated identifiers.

A good implementation uses the platform's cryptographically secure random source. Ad hoc generators, predictable seeds, cloned generator state, or failure to reseed after a process fork can undermine both collision resistance and unpredictability. The LiveParse UUID v4 Generator creates random IDs in the browser, while the UUID collision probability guide explains why the ideal mathematical risk and real generator failures must be analyzed separately.

Randomness does not provide ordering. Two successive v4 values have no chronological relationship, and random primary-key inserts can have weaker index locality than a time-ordered design. They also have no embedded timestamp, which is helpful when disclosing creation time is undesirable.

UUIDv6: v1 fields reordered for sorting

UUIDv6 reorders the v1-compatible 60-bit Gregorian timestamp from most significant to least significant position. The clock sequence and node concepts remain, but putting time first allows opaque byte comparison to follow timestamp order more naturally and improves locality for many ordered indexes.

The standard expects v6 primarily where v1 compatibility matters. Systems without that legacy requirement should use v7 instead. Because v6 retains v1's timestamp source and node field, it shares the same time-disclosure and potential host-identifier concerns. A random node reduces host identification but does not hide creation time.

UUIDv7: Unix milliseconds first

UUIDv7 begins with an unsigned 48-bit count of Unix epoch milliseconds. After the version field, 12 bits called rand_a appear; the variant is followed by 62 bits called rand_b. Together those two payload fields provide 74 bits that a basic generator can fill with random data. RFC 9562 also permits carefully ordered sub-millisecond fractions and counters for stronger monotonic behavior.

Across different millisecond values, RFC bytewise and standard textual ordering are primarily chronological. Within the same millisecond, an all-random-tail generator does not guarantee generation order. A stateful generator can add monotonic behavior, but it must define counter overflow, concurrent calls, process boundaries, and clocks that move backward.

The first 48 bits are decodable, so v7 exposes an approximate creation time. RFC 9562 also allows timestamp alteration, fuzzing, or smearing, and the clock may simply be wrong. Treat the decoded time as format metadata, not authenticated evidence of when a database committed a record. Keep a separate authoritative timestamp where audit semantics matter. Generate and inspect the layout with the UUID v7 Generator, or compare tradeoffs in the UUID v4 vs v7 guide.

UUIDv8: custom or experimental layouts

UUIDv8 reserves the version and RFC variant fields, leaving 122 bits for an implementation-specific layout. It exists for experimental, vendor-specific, or standards-defined schemes that do not fit versions 1 through 7. Examples include a custom timestamp source or a name-based construction using SHA-256.

The version number alone says nothing about how those 122 bits are divided. Two unrelated v8 schemes can produce strings that look structurally valid yet cannot interpret each other's payload. A v8 design needs a published bit layout, generation algorithm, byte order, collision strategy, security analysis, and interoperability boundary.

RFC 9562 explicitly says v8 uniqueness is implementation-specific and must not be assumed. It is not “v4 with extra freedom,” nor does the higher version number make it stronger. If 122 random bits are the requirement, use v4. If Unix-millisecond ordering is the requirement, use v7.

Nil and Max are special sentinel UUIDs

The Nil UUID has every bit set to zero. It can represent the absence of another UUID in a field that must remain 128 bits wide:

00000000-0000-0000-0000-000000000000

The Max UUID has every bit set to one and can serve as an application-defined upper or end sentinel:

ffffffff-ffff-ffff-ffff-ffffffffffff

Neither is an ordinary instance of versions 1 through 8. Nil falls in the reserved NCS variant range and Max in the future-reserved variant range. Decide explicitly whether an API accepts these sentinels; “valid UUID-shaped text” and “valid identifier for this record” are different validations.

Timestamp and privacy comparison

Any exposed identifier can support correlation across logs, URLs, exports, and services. Avoid embedding sensitive business facts in a custom v8 layout, and do not treat opacity as access control. RFC 9562 warns that UUIDs must not be used as security capabilities whose mere possession grants access.

How to choose a UUID version

1. Choose v4 for independent random IDs. Use a vetted CSPRNG-backed platform API and enforce uniqueness where records are stored.
2. Choose v7 for new time-ordered IDs. Confirm the library's same-millisecond, rollback, and concurrency behavior; retain a separate business timestamp.
3. Choose v5 for deterministic names. Freeze the namespace and canonical byte rules before generating persistent values.
4. Use v6 for v1-oriented compatibility. Do not select it merely because six is higher than four.
5. Use v8 only with a documented scheme. Give consumers a specification and collision/security analysis, not just a version label.
6. Treat v1, v2, and v3 as compatibility formats. Understand their legacy requirements before introducing them into a new protocol.

Whatever version you select, validate the expected variant and version at input boundaries. Add a database UNIQUE or primary-key constraint when duplicate records would be harmful. Keep authentication, authorization, integrity, and audit timestamps separate from the identifier.