What is a UUID, and when should you use one?

You have probably seen a string like f47ac10b-58cc-4372-a567-0e02b2c3d479 in a URL, a database, or a config file and wondered what it is and why it is so long. That is a UUID, and its whole job is to be a unique identifier that any machine can generate on its own, with no shared counter and almost no chance of clashing with anyone else’s. Knowing how it works tells you exactly when to use one and when a plain number is the better tool.

TL;DR: A UUID is a 128-bit identifier, usually shown as 32 hex digits in five groups (8-4-4-4-12). It exists so any machine can mint an ID independently and still avoid collisions, with no central server. Random (version 4) UUIDs are practically guaranteed unique. Use one for distributed or client-generated IDs and for public IDs that should not be guessable; reach for a plain auto-increment integer when a single database owns the keys.

What a UUID actually is

A UUID is a 128-bit value. To make those bits readable, they are written as 32 hexadecimal digits grouped 8-4-4-4-12 and joined by hyphens, like 550e8400-e29b-41d4-a716-446655440000. The hyphens carry no meaning; they just break up the run of digits. The full name is universally unique identifier, and GUID, the term you see in Microsoft tools, is the same thing under a different label.

The point of all those bits is range. With 128 bits there are roughly 3.4 times 10 to the 38 possible values, a number so large that picking one at random and ever picking it again is, for practical purposes, not going to happen. That enormous space is what lets the scheme make its central promise: that an ID generated on one machine will not collide with one generated on another, even though the two never coordinated.

Why UUIDs exist at all

The problem UUIDs solve is generating an identifier with no central authority. A classic database hands out IDs from a single counter: row 1, row 2, row 3, each number issued by one server that knows what it gave out last. That works beautifully until you have many servers, offline clients, or systems that must create records without phoning home first. Two of them will both reach for “the next number” and clash.

A UUID sidesteps the counter entirely. Instead of asking a server for the next value, a machine generates a UUID locally from randomness or a timestamp, and trusts the huge value space to keep it unique. No coordination, no round trip, no single point that everyone has to ask. A phone in airplane mode can create a record’s ID, and a server can create another, and when they later sync, the two IDs will not collide. That independence is the entire reason the format exists.

How unlikely is a collision, really

For a version 4 UUID, which fills its bits with randomness, a collision is possible in theory and ignorable in practice. A v4 UUID fixes a few bits to mark its version and variant, leaving 122 random bits, which is about 5.3 times 10 to the 36 distinct values. To have even a one-in-a-billion chance of a single duplicate, you would need to generate on the order of a quintillion UUIDs.

Put in everyday terms, you could generate a billion v4 UUIDs every second for roughly a century and still be more likely to win a major lottery repeatedly than to see one collision. So while “universally unique” is not a mathematical guarantee, the gap between theory and reality is so wide that production systems treat v4 UUIDs as unique without a second thought. You can mint one yourself with a free UUID generator at dev.hivly.net and see the format directly.

The common versions, and why v7 matters

UUIDs come in several versions, and the digit that starts the third group tells you which one you are holding. The two you meet most are version 4 and the time-based versions. A version 4 UUID is built from random bits, so it carries no information about when or where it was made; it is pure randomness inside the fixed layout. That randomness is exactly what makes it a good public ID, since you cannot guess the next one.

Version 1 is the old time-based design, mixing a timestamp with the machine’s network address, which raised privacy concerns because it could leak hardware identity. Version 7 is the modern time-based option, and it fixes the interesting weakness of v4: ordering. A v7 UUID puts a millisecond timestamp at the front, so sorting v7 UUIDs as text sorts them by creation time. That sounds minor, but it matters a lot for databases, where random v4 keys scatter inserts across an index and v7 keys land in order, keeping the index tidy and faster to write.

When to use a UUID, and when not to

Reach for a UUID when IDs are born in many places that cannot share a counter: distributed services, multiple databases, or clients that generate keys offline before syncing. Use one when you want a public-facing ID that does not expose how many records you have or let someone walk the sequence. A URL ending in /orders/8 invites guessing /orders/9; a URL ending in a UUID does not.

A plain auto-increment integer is the simpler, often better choice when one database owns all the IDs. Integers are tiny next to a 128-bit value, they index faster, they are easy to read and type, and they sort naturally. The cost of a UUID is real: it takes more space, it is slower to index when random, and nobody reads one aloud comfortably. So the decision is not “UUIDs are modern, integers are old.” It is about who creates the IDs and whether the value needs to stay opaque. If a single server owns the keys and they can be sequential, use an integer. If creation is spread out or the ID must not be guessable, use a UUID, and prefer v7 when you also want them to sort by time.