> With Hexadecimal, we get 4 bits per character. With Base64, we get 6 bits per character. To keep UUIDs at 128 bits, we'd go from 32 to 22 characters in length

> With Hexadecimal, we get 4 bits per character. With Base64, we get 6 bits per character. To keep UUIDs at 128 bits, we'd go from 32 to 22 characters in length. ... Additionally, why the dashes? In a string, that dash takes up just as much wasted space as the additional characters which are providing data utility. Instead of base64, sensible databases and libraries store UUIDs as "base256". Actual binary strings of 128 bits = 16 bytes, not printable ASCII. That is the shortest possible representation, with zero wasted space. The hexadecimal representation is only used for displaying UUIDs to humans. It doesn't have to be efficient, it has to be helpful. For UUID version 1, the dashes separate clock, counter and MAC address parts in the data. With hex encoding it is easy to convert to/from binary and for "popular numbers" even to decimal in your head without running it through a baseXX converter. For UUID version 4, where the data is all completely random, it's less useful. All you can do with it is compare two UUIDs. So there perhaps the human-friendly representation could do without dashes and use a larger base.