UUID Versions Explained: v4 vs v1, v5, v7 and v8 (Format & Length)

Version M and variant N

RFC 9562 §4 writes every UUID as five hex groups. The first digit of the third group is the 4-bit version. The first two bits of the fourth group are the variant; variant 10 makes that digit 8, 9, a, or b. Changing case or stripping hyphens does not change those bits.

That string is RFC 9562 Appendix A.3’s UUIDv4 example: the 4 in 4320 is the version; the 9 in 9bac is a legal variant-10xx nibble.

v4: 122 random bits

RFC 9562 §5.4 fills random_a, random_b, and random_c (122 bits) from a random or pseudorandom source, then overwrites the version (4) and variant (10). WHATWG crypto.randomUUID() is specified as that version 4 UUID. Successive values are not time-ordered. Section 1 of the RFC notes the B-tree locality cost of inserting them as primary keys. They still are not secrets and are not checked against a registry here.

v1 and v6: Gregorian 100-nanosecond time

UUIDv1 (§5.1) stores a 60-bit count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582 UTC, plus a 14-bit clock sequence and a 48-bit node field (often a MAC). The timestamp is split low / mid / high, so a lexical sort of the 36-character string is not chronological. UUIDv6 (§5.6) uses the same clock but stores the 48 most significant time bits first so the string sorts with time. The RFC says systems without a v1 legacy should use v7 instead. A node field that is a MAC can identify a machine; this page never reads a MAC.

v7: Unix milliseconds in the high bits

UUIDv7 (§5.7) puts a 48-bit Unix epoch timestamp in milliseconds (since 1970-01-01T00:00:00Z, leap seconds excluded) in bits 0–47, then version 7, then 74 remaining bits that are random or an optional monotonic counter. Implementations SHOULD use v7 instead of v1 or v6 when they want a time-ordered UUID. The v7 generator mints that layout. It does not implement §6.2 monotonic counters and does not extract a clock from a pasted string.

v3 and v5: namespace plus name

Both versions hash a 16-octet Namespace ID concatenated with a name (§6.5). v3 uses MD5 (§5.3); v5 uses SHA-1 and keeps the leftmost 128 bits of the 160-bit digest, discarding the rest (§5.5). The version and variant bits then overwrite the matching hash bits. The same namespace and name always yield the same UUID. The RFC prefers v5 over v3. A SHA-256 name-based ID MUST be UUIDv8, not v5. The v5 generator assembles that SHA-1 layout. The sample generates output is DNS www.example.com → 2ed6657d-e927-568b-95e1-2665a8aea6a2 (RFC 9562 Appendix A.4). Name bytes are UTF-8 of the typed string, not DNS wire format. Docify’s hash generator can SHA-1 the name alone and does not assemble a UUID. v3 (MD5) is still not minted.

UUID v8 (RFC 9562 §5.8) reserves 122 bits for implementation-defined layouts. The version nibble is 8, and the variant bits follow the standard 10xx pattern, but everything else is up to you.

Some organizations use v8 to embed custom timestamps, shard IDs, or other domain-specific data. The RFC explicitly notes that v8 is not a replacement for filling those bits with v4 random data — if you just need a random ID, use v4. If you need time-ordering, use v7.

Because v8 layouts are implementation-specific, this site does not generate them. The UUID v4 generator and UUID v7 generator cover the most common use cases.

For most applications, UUID v4 is the right choice — it is simple, widely supported, and has negligible collision probability with 122 random bits. If you need time-ordered IDs for database primary keys, UUID v7 preserves insertion order and improves index locality. Use v5 when you need deterministic IDs derived from a namespace and name. The other versions are legacy (v1, v6) or special-purpose (v2, v3, v8).

All versions are 128 bits (16 bytes). With hyphens: 36 characters. Without hyphens: 32 characters.