UUID Decoder

How the UUID Decoder works

UUID decoder: versions and variants

A UUID is 128 bits written as 32 hex digits in five groups, 8-4-4-4-12. Two small fields inside it are fixed by the standard: the first hex digit of the third group is the version, and the top two or three bits of the fourth group are the variant. Everything else depends on the version, which is what makes decoding useful: a v4 UUID is just random bits, but a v1 or v7 UUID carries a timestamp that tells you when a record was created, and a v1 UUID may carry the MAC address of the machine that created it.

Version 7. The first 48 bits are the Unix time in milliseconds, big-endian, so the decoder reads them straight into a date. The remaining 74 bits are random (12 bits of rand_a, which some generators use as sub-millisecond precision or a counter, and 62 bits of rand_b). Because the timestamp leads, v7 UUIDs sort by creation time, which is why they have replaced v1 and v4 as the default for database keys in RFC 9562.

Version 1. The timestamp is a 60-bit count of 100-nanosecond intervals since 15 October 1582, the start of the Gregorian calendar, split into low, mid and high parts with the low part first. The decoder reassembles it and subtracts the 12,219,292,800 seconds between 1582 and 1970 to give Unix time. The 14-bit clock sequence guards against the clock being set backwards, and the 48-bit node is the generating machine's MAC address unless the generator chose a random value, in which case the multicast bit (the least significant bit of the first byte) is set. That MAC leak is the reason v1 fell out of favour.

Version 6. The same Gregorian timestamp as v1 but with the parts reordered so the high bits come first and the UUID sorts chronologically. Otherwise identical in layout.

Versions 3, 4, 5 and 8. Nothing to recover. v3 and v5 are MD5 and SHA-1 hashes of a namespace and a name, and the hash cannot be reversed. v4 is 122 random bits. v8 is reserved for custom layouts, so its contents mean whatever the application decided. Version 2 is the DCE Security variant, rare in practice, which replaces the low timestamp with a POSIX UID or GID and stores a domain byte in place of the low clock sequence.

Variant. The nibble at position 17 says which family the layout belongs to. 8, 9, a or b is the RFC 4122 / 9562 layout that every modern UUID uses. 0 to 7 is the old NCS layout, c and d are reserved for Microsoft's legacy COM GUIDs, and e and f are reserved. The version digit only has its standard meaning within the RFC variant, which is why the decoder reports n/a for the others.

Nil and Max. All zeros and all ones are special values defined by the RFC, used as placeholders and sentinels. The decoder names them rather than trying to read a version out of them.

UUID decoding worked examples

The formula: version = the 13th hex digit; variant = the top bits of the 17th hex digit (8, 9, a or b means RFC 9562); for version 7, timestamp = the first 12 hex digits read as milliseconds since 1970-01-01 UTC.

First example. F47ac10b-58cc-4372-a567-0e02b2c3d479: the 13th digit is 4, so version 4, random. The 17th digit is a, binary 1010, so the RFC variant. There is no timestamp to extract.

Second example. 01a11ad9-21c0-7abc-9def-0123456789ab: the 13th digit is 7. The first 12 hex digits, 01a11ad921c0, are 1,791,451,800,000 in decimal, which is 2026-10-08 09:30:00.000 UTC.

How many UUIDs are possible? A version 4 UUID has 122 random bits, about 5.3 × 10^36 values, so two random UUIDs effectively never collide.

Version 7 UUID prefix at the start of each month (UTC)

Related tools