[teeray]

I just wish there was some human element to them so they were easier to talk about. Something like:

BASKETBALL-9a176cbe-7655-4850-9e7f-b98c4b3b4704-FISH

CAKE-3a01d58f-59d3-4b0c-87dc-4152c816f442-POTATO

“Which row was it, ‘basketball fish’ or ‘cake potato’?

Of course, the words would need to be a checksum. As soon as you introduce them, nobody is looking at the hex again. Which is an improvement, since nobody is looking at all the hex now “it’s the one ending in ‘4ab’”.

[tgv]

There's nothing stopping you from doing so. You don't have to use strict UUIDs. Their form rarely serves a real purpose anyway.

But for exposed values (document ids, customer ids, that kind of thing), it can be awkward if a patient's id is suddenly "CRANKY-...-FART".

[kstrauser]

If I discovered that were my patient ID, I would laugh myself into unconsciousness and buy the staff a pizza.

[VLM]

There's been a lot of historical work done in the past and I used NIST FIPS181 to implement this.

Note: FIPS181 was intended for passwords and I was using them as handy short human-readable record IDs as per your post. You probably shouldn't use FIPS181 for passwords in 2026 LOL.

Describing FIPS181 as pronounceable is optimistic. However its better than random text wrt human conversations. They start looking like mysterious assembly language mnemonics after awhile.

[tomwphillips]

At $dayJob we use (user facing) IDs like this. Select a prefix then add a sufficient number of random alphanumeric characters for your use case.