Not quite random.
A UUID looks like 32 random hex digits. One of them names the version, and the version decides what the others are made of: time, a hash, a machine, or chance.
Version 1. A 100-nanosecond clock, a clock sequence and a node id. The 1990s original; it does not sort.
Field by field
What each part of the UUID above is for, and what these particular digits say.
- time_low32 bits
The lowest 32 bits of a 60-bit clock that counts 100-nanosecond steps from 15 October 1582. The fastest-moving bits come first, which is why v1 ids do not sort.
- time_mid16 bits
The middle 16 bits of the clock.
- ver4 bits
The version, always the 13th digit. 1 means Gregorian time and node. In binary,
0001. - time_high12 bits
The top 12 bits of the clock. Together they say
2022-02-22 19:22:22.0000000UTC. - var2 bits
The variant: the first two bits of digit 17, always 10 in an RFC 9562 UUID. That is why digit 17 is 8, 9, a or b. Here
bis1011: the variant, then two bits of clock_seq. - clock_seq14 bits
A counter the generator bumps when its clock goes backwards, so a repeated time still gives a new id.
- node48 bits
Originally the MAC address of the machine. Generators now use random bits and set the multicast bit to say so. Here
9f:6b:de:ce:d8:46, with the multicast bit set: random.
Every version, one grid
The examples printed in RFC 9562. Whatever the version, the 13th digit names it and the 17th carries the variant.
Which one? For database keys, v7: it sorts by the time it was made. For ids that should give nothing away, v4. When the same name must always map to the same id, v5. The rest serve old systems (v1, v3), moves off v1 (v6) and layouts of your own (v8). There is no v2: RFC 9562 leaves it to DCE Security.