Exactly. Also, not everything is going to be an URL, or human-visible at all. Others have noted the usefulness of generating ids for user-created data without

Exactly. Also, not everything is going to be an URL, or human-visible at all. Others have noted the usefulness of generating ids for user-created data without involving the server, while being able to post that data at a later time without worrying too much about collisions. Suspenders-and-belt practice would of course dictate that the server do some type of collision detection and mitigation before storing the received data. If UUID exists in database and user ID is different, tell client "Yo, we've got a collision here. Your new ID for this data is blah". On the client end, when creating the data, Generate new UUID. If I've ever used that UUID before, generate a new one. When the client saves the data to the server If the server rejects my UUID, switch to the new one provided by the server In practice the collision mitigation code is likely never to be called, even in a very large system. The people who designed UUID went to great lengths to ensure that. Personally, I'd look on home-brewed solutions for generating unique "friendly ids" with the same deep suspicion I look at home-brewed crypto, particularly if this were done client-side for multiple clients without involving a server round-trip. Getting it right is a Hard Problem. The perceived complexity of UUIDs is there precisely because it is a Hard Problem.