What Is a UUID? Why Random IDs Power Modern Software

If you have ever looked inside a modern database, a log file, or an API response, you have seen strings like f47ac10b-58cc-4372-a567-0e02b2c3d479. That is a UUID — a Universally Unique Identifier — and it has quietly become one of the most important building blocks of distributed software. This article explains what UUIDs are, how they work, and why engineers reach for them so often.

The problem UUIDs solve

Imagine two servers, in two data centers, both creating new user records at the same moment. If each used a simple counter (1, 2, 3…), they would both mint user number 5,001 and collide the instant their data merged. The classic fix is a central authority that hands out IDs — but that authority becomes a bottleneck and a single point of failure.

UUIDs remove the authority entirely. They are 128-bit numbers designed so that anyone, anywhere, can generate one at any time with a vanishing chance of ever producing the same value as someone else. No coordination, no central counter, no bottleneck.

Anatomy of a UUID

A UUID is written as 32 hexadecimal digits in five hyphen-separated groups: 8-4-4-4-12. The most common kind today is version 4, which is almost entirely random:

f47ac10b-58cc-4372-a567-0e02b2c3d479
              ^              ^
              |              variant (8,9,a,b)
              version (4)

One digit marks the version (the 4) and one marks the variant; the remaining 122 bits are random. Other versions exist — version 1 mixes in a timestamp and the machine's MAC address, version 7 (newer) embeds a sortable timestamp — but version 4 is the default choice when you just need an unguessable, unique value.

Can two UUIDs ever collide?

In theory, yes. In practice, never. With 122 random bits there are roughly 5.3 undecillion (5.3 × 10^36) possible version 4 UUIDs. To reach even a 50% chance of a single collision, you would need to generate about a billion UUIDs every second for around 85 years. The numbers are so large that engineers treat collisions as impossible and design accordingly.

UUIDs versus auto-increment integers

Databases traditionally use auto-incrementing integers (1, 2, 3…) as primary keys. So when should you use a UUID instead? Here is the trade-off:

• Use UUIDs when records are created across multiple servers, when IDs must be unguessable (so users cannot enumerate /users/1, /users/2…), or when you need to generate the ID before inserting the row.
• Use integers when you have a single database, storage size matters, and index performance is critical — a 4-byte integer is far smaller than a 16-byte UUID and sorts faster.

Many teams use both: an integer primary key internally for performance, and a UUID exposed publicly so external identifiers reveal nothing about volume or order.

Practical tips

1. Store them efficiently. If your database has a native UUID type, use it — it stores the value in 16 bytes instead of 36 characters of text.
2. Do not rely on the order. Version 4 UUIDs are random, so they do not sort chronologically. If you need time-ordered IDs, look at version 7.
3. They are not secrets. A UUID is unguessable but not encrypted. It is fine in URLs, but do not use one as a password or API secret.

Need a few right now? Generate version 4 UUIDs instantly with the tool below — they are created locally in your browser using a cryptographically secure random source.