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 4. 122 random bits around the six that every UUID fixes. The kind most tools print.

919108f7-52d1-4320-9bac-f847db4148a8
The example printed in RFC 9562.

Field by field

What each part of the UUID above is for, and what these particular digits say.

  1. random_a48 bits

    Random bits from a cryptographically secure generator.

  2. ver4 bits

    The version, always the 13th digit. 4 means random. In binary, 0100. The random source had put a 3 here; the version took its place.

  3. random_b12 bits

    More random bits.

  4. 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 9 is 1001: the variant, then two bits of random_c.

  5. random_c62 bits

    The last random bits. With the others that makes 122, about 5.3 × 10³⁶ possible ids. At a billion ids a second, even odds of one collision take 86 years.

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.