UUID v6 Generator

About UUID v6

UUID v6 is one of three time-ordered UUID variants standardised in RFC 9562 (May 2024), alongside v7 and v1. It exists for a specific reason: to give systems already using v1 a way to gain better database index locality without changing the fundamental shape of their identifier strategy.

A v6 UUID carries the same conceptual fields as v1 — a 60-bit timestamp, a 14-bit clock sequence, and a 48-bit node identifier — but the timestamp's bytes are rearranged so the most significant bits come first. When v1 UUIDs are compared as binary or sorted lexicographically as strings, they appear effectively random because the high-entropy parts of the timestamp sit in the middle of the value. v6 fixes this by placing the high bits of the timestamp at the start of the UUID, which means two v6 UUIDs generated milliseconds apart will sort adjacent to each other.

The timestamp itself counts 100-nanosecond intervals since 15 October 1582 — the date the Gregorian calendar was adopted — which is the same epoch used by v1 and inherited from earlier distributed-system specifications. This unusual choice gives v6 a timestamp precision of 100 nanoseconds and a maximum representable date well into the future (around the year 5236).

The node field was originally meant to hold the MAC address of the generating machine, providing spatial uniqueness alongside the timestamp's temporal uniqueness. RFC 9562 explicitly permits substituting a random 48-bit value for the node, with bit 0 of the first octet set to 1 to signal that it's not a real MAC address. This generator uses random node values — browsers cannot access MAC addresses, and even if they could, the privacy implications would make using them undesirable.

When to use UUID v6

The honest answer for new projects: probably never. UUID v7 is simpler, has more randomness in the lower bits, uses the standard Unix epoch, and gets native support from most language runtimes. For greenfield work where you want a time-ordered UUID, v7 is the better default.

UUID v6 is the right choice in one specific scenario: you have an existing system built around UUID v1, and you want to switch to a sortable variant without changing the conceptual structure of your identifiers. v6 preserves v1's clock sequence and node fields, which means existing code that introspects those fields continues to work. You're effectively rotating the bytes of an otherwise familiar identifier.

If you're building something new and haven't already committed to v1's structure, the migration argument doesn't apply. v7 wins on simplicity, ecosystem support, and randomness budget.

Working with UUID v6

Two practical notes worth knowing:

Byte order matters at storage boundaries. Like v7, v6's sort property only holds when the value is compared as RFC byte order — high bytes first. Several platforms (notably .NET's Guid type and SQL Server's uniqueidentifier) store the first three fields of a UUID in a non-standard layout that breaks the sort property when compared as binary. If you persist v6 UUIDs in such systems and need the sort property preserved, convert to RFC byte order at the storage boundary or store as BINARY(16) rather than the platform's native UUID type. This is the same pitfall covered in detail in the .NET v7 byte-order article.

Random node values are not personally identifying. A v6 UUID generated by this site cannot be traced back to your machine, network, or any persistent identifier. The node field is freshly random each time the generator runs and is marked accordingly per the RFC.

Generating v6 in code

// .NET 10 has no built-in v6 helper. Assemble manually:
Span<byte> bytes = stackalloc byte[16];
var ticks = DateTime.UtcNow.Ticks - new DateTime(1582, 10, 15, 0, 0, 0, DateTimeKind.Utc).Ticks;
// ... pack ticks into bytes 0-7, set version=6, variant=10xx,
// fill bytes 8-15 with random, set bytes[10] |= 0x01.
var id = new Guid(bytes, bigEndian: true);

from uuid_utils import uuid6
id = uuid6()

FAQ