The bit layout of a UUID

byte array9 sectionsUpdated

Every UUID spends 4 bits on the version and 2 on the variant. The other 122 belong to the layout that the version names, and the tables below come straight out of the code this site runs.

A UUID is 128 bits and only six of them mean the same thing in every version. This page maps the rest: which bit ranges belong to the clock, the node, the hash or the randomness, for every layout RFC 9562 defines.

Open the converter: byte arrayNothing you paste leaves the browser.

On this page (9)

The six bits every version shares#

Bits 48 to 51 hold the version: that is the 13th hex digit of the printed form, the first character of the third group. Bits 64 and 65 hold the variant, at the top of the 17th hex digit, which is the first character of the fourth group. A 10xx pattern there means RFC 9562, which is why so many identifiers show 8, 9, a or b in that position.

RFC 9562 § 4.2 · Version FieldThe version field

RFC 9562 § 4.1 · Variant FieldThe variant field, and the patterns that are not this standard

Version 4: randomness with two holes in it#

random 0-47version 48-51random 52-63variant 64-65random 66-127

Two fixed fields cut the randomness into three runs, 122 bits in total.
FieldBitsWidthKind
random0-4748random
version48-514version
random52-6312random
variant64-652variant
random66-12762random

The two fixed fields split the random space into three runs. That is why a v4 has 122 bits of entropy rather than 128, and why the 13th and 17th characters of a v4 never look random.

Version 7: milliseconds first#

unix_ts_ms 0-47version 48-51rand_a 52-63variant 64-65rand_b 66-127

The millisecond clock leads, so byte order and time order agree.
FieldBitsWidthKind
unix_ts_ms0-4748timestamp
version48-514version
rand_a52-6312random
variant64-652variant
rand_b66-12762random

The 48-bit millisecond field sits at the front, so byte order and time order agree and the identifiers sort. rand_a is nominally random, but a generator is allowed to spend it on sub-millisecond precision or on a counter that keeps identifiers made in the same millisecond in order.

RFC 9562 § 5.7 · UUID Version 7The v7 layout in the standard

Version 1: the clock that does not sort#

time_low 0-31time_mid 32-47version 48-51time_high 52-63variant 64-65clock_seq 66-79node 80-127

The clock is split into three pieces and the high part comes last, which is why a v1 does not sort.
FieldBitsWidthKind
time_low0-3132timestamp
time_mid32-4716timestamp
version48-514version
time_high52-6312timestamp
variant64-652variant
clock_seq66-7914clock sequence
node80-12748node

The clock is split into low, mid and high, and the high part comes last. Sorting v1 identifiers as strings therefore sorts by the low bits of the clock, which is close to sorting by nothing. Version 6 fixes exactly this by putting the pieces back in order.

Version 6: the same clock, reordered#

time_high 0-31time_mid 32-47version 48-51time_low 52-63variant 64-65clock_seq 66-79node 80-127

The same clock as a v1, written most significant bits first.
FieldBitsWidthKind
time_high0-3132timestamp
time_mid32-4716timestamp
version48-514version
time_low52-6312timestamp
variant64-652variant
clock_seq66-7914clock sequence
node80-12748node

Versions 3 and 5: a hash with the middle cut out#

sha1_high 0-47version 48-51sha1_mid 52-63variant 64-65sha1_low 66-127

A SHA-1 digest with six bits overwritten.
FieldBitsWidthKind
sha1_high0-4748hash of the name
version48-514version
sha1_mid52-6312hash of the name
variant64-652variant
sha1_low66-12762hash of the name

A v5 is a SHA-1 of the namespace and the name, truncated to 128 bits, with the version and variant bits overwritten. A v3 is the same with MD5. Six bits of the digest are lost, which is intentional and harmless: what remains is still a deterministic function of the input.

RFC 9562 § 6.5 · Name-Based UUID GenerationHow a name-based identifier is derived

Version 8: nothing but the six bits#

custom_a 0-47version 48-51custom_b 52-63variant 64-65custom_c 66-127

Only the version and variant are spoken for; the other 122 bits are yours.
FieldBitsWidthKind
custom_a0-4748random
version48-514version
custom_b52-6312random
variant64-652variant
custom_c66-12762random

Version 8 exists so that a custom layout can still be a valid UUID. The standard claims the version and variant bits and says nothing about the other 122, which makes v8 the right home for identifiers that embed a shard number, a tenant, or a different clock.

RFC 9562 § 5.8 · UUID Version 8The deliberately empty specification for v8

Questions people actually ask#

Which character of a UUID is the version?

The 13th hex digit, which is the first character of the third group. A v4 shows a 4 there and a v7 shows a 7.

Why does the fourth group almost always start with 8, 9, a or b?

Those are the values whose top two bits are 10, which is the variant that marks an RFC 9562 identifier.

How much entropy does a v4 actually have?

122 bits. The version and variant take six of the 128.

Browse the reference