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 3. Name-based, with MD5: the same namespace and name always give the same id. Prefer v5 for anything new.
Field by field
What each part of the UUID above is for, and what these particular digits say.
- md5_high48 bits
The first 48 bits of the MD5 hash of the namespace followed by the name.
- ver4 bits
The version, always the 13th digit. 3 means an MD5 hash of a name. In binary,
0011. MD5 had put a0here; the version took its place. - md5_mid12 bits
The next 12 bits of the hash. The four before them gave way to the version.
- 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
8is1000: the variant, then two bits of md5_low. - md5_low62 bits
The last 62 bits of the hash. The same namespace and name give this id anywhere.
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.