What Is a UUID and When Should You Use One?

A UUID is a long string generated to uniquely identify a record. The reason to use one instead of a simple incrementing ID is that the chance of a collision is practically zero even when different systems generate IDs independently at the same time.

Summary

Step by step

Decide whether you actually need one: if multiple systems are generating records without talking to each other, a UUID makes sense; a single central database usually does fine with a simple incrementing ID.
Generate a sample ID with a UUID generator and get familiar with the format (32 characters in 5 dash-separated groups).
Remember a UUID isn't sequential. If you want to list records in creation order, you need a separate date field for that.
In a database, store it as a proper binary/UUID type rather than plain text. The performance difference is real.

Why it matters

With incrementing IDs, the record number leaks information. Someone who sees /order/1042 in the address bar may try 1041 and 1043, or get a rough idea of how many orders you've processed. A UUID makes that guessing much harder. It also lets a client that works offline, like a mobile app, assign IDs to its own records without asking the server. When the data syncs later, there's nothing to collide.

A closer look at the format

A UUID is 32 hexadecimal digits. Split into groups of 8-4-4-4-12 with dashes, it comes to 36 characters. The first digit of the third group tells you the version. Version 4 is the most common and is almost entirely random. The newer version 7 puts a timestamp at the front, so records sort roughly in creation order and database indexes stay tidier. You can tell which one you're looking at from that version digit.

Common mistakes

Using a UUID as a secret. It's hard to guess, but it wasn't designed as a security token. For things like password reset links, use random tokens generated for that purpose.
Letting the UUID stand in for access control. If anyone who knows the URL can open the record, the problem is authorization, not the ID type.
Making a random UUID the primary key on a huge table and only noticing the performance hit later. Random values scatter across the whole index. Time-ordered versions soften that.
Storing a mix of uppercase and lowercase UUIDs. Compared as plain text, the same ID can look like two different records.

A realistic scenario

A booking app wants people to draft appointments even without an internet connection. With incrementing IDs, two phones generate the same number and records overwrite each other during sync. The team switches to a UUID created on the device for every draft. A separate created-at field handles sorting, and the short booking number shown to the user is assigned by the server afterwards.

If users need to see it

A 36-character ID is painful to read over the phone or give to a support agent. Keep the UUID as the internal ID and show users a short, readable reference code. That covers both needs.