UUID Explained: What They Are and Why Developers Use Them

If you have ever looked closely at a URL, a database row, or a log file, you have probably met a UUID: one of those long strings of letters and numbers, such as 6ba7b810-9dad-11d1-80b4-00c04fd430c8. This guide explains what a UUID is, how one is generated, why duplicates are so unlikely, and when you should use one.

What is a UUID?

UUID stands for Universally Unique Identifier: a 128-bit number that software uses to label things. A row in a database, a file in cloud storage, an order in a shop, a message in a queue: any object that needs a name no one else will reuse can carry a UUID.

A UUID is usually written as 32 hexadecimal digits split by hyphens into the 8-4-4-4-12 pattern, like this:

6ba7b810-9dad-11d1-80b4-00c04fd430c8

Each group is a slice of the same 128-bit value. Only the digits 0-9 and the letters a-f appear, because a UUID is just a large number in hexadecimal. Hyphens included, the string is 36 characters long.

"Universal" is the key word: no central authority hands these numbers out. Any computer, anywhere, can create a UUID and be confident that no other machine has produced the same value. That property is what makes UUIDs so useful.

How UUIDs are generated

Look at the third group in the example above, 11d1: its first digit is the version number, which records how the UUID was built. The first digit of the fourth group is the variant, which records the layout standard. Two strategies produce almost all UUIDs in the wild.

Version 4 (random). A version 4 UUID is built from random bytes: 122 of its 128 bits are chosen at random, and the remaining 6 mark the version and variant. One looks like f47ac10b-58cc-4372-a567-0e02b2c3d479, where the third group starts with 4. Because the bits come from chance rather than a clock or machine address, a version 4 UUID reveals nothing about when or where it was made.

Version 1 (time-based). A version 1 UUID combines a precise timestamp, a clock sequence that guards against clock rollbacks, and a node identifier, traditionally the machine's MAC address. Because the timestamp moves forward, version 1 UUIDs are roughly ordered by creation time, which is friendlier to indexes, but they leak when, and often where, a value was made.

There are other versions: version 3 and version 5 derive a UUID from a name using a hash, so the same input yields the same UUID. For day-to-day work, choose version 4 unless you have a reason not to.

How unique is a UUID, really?

Unique enough to seem impossible, and that is by design: a version 4 UUID draws on 122 random bits, about 5.3 undecillion possible values, which is about five trillion times more UUIDs than there are stars in the observable universe.

Thanks to the birthday paradox, you do not need to fill the space for a repeat: the chance of a collision grows with the square of how many UUIDs you create. Even so, generate one billion UUIDs every second and you would still need about 70 years before a 50 percent chance of one duplicate.

Version 1 UUIDs earn their uniqueness from a timestamp, a clock sequence, and a node identifier rather than pure randomness, but the conclusion is identical: for any workload a real team can run, collisions do not happen. Treat the 2^122 odds like gravity.

UUID vs GUID: what is the difference?

Nothing, in practice. GUID stands for Globally Unique Identifier, the name Microsoft chose for the same concept. Both terms describe the same 128-bit value, the same 8-4-4-4-12 textual format, and the same standard (RFC 4122). When you read about GUIDs in .NET, C#, or Windows documentation, you are reading about UUIDs.

There is one nuance: Windows historically stored GUIDs in a mixed-endian byte order, but that never shows in the textual form and never matters in day-to-day code. UUID vs GUID is only a naming difference.

When to use a UUID (and when not to)

UUIDs earn their keep in a handful of situations:

• Distributed systems. When rows are created on phones, laptops, or edge servers and synced later, every client can mint its own key offline, with no counter to coordinate.
• Merging data. When two databases are combined, UUID keys cannot clash, so nothing needs renumbering.
• Public identifiers. Order numbers and share links should not reveal your business volume. An auto-incrementing ID of 100231 hints at how many orders you took yesterday; a UUID tells competitors nothing.
• Cross-service correlation. Events traveling between microservices can carry one shared ID, which makes tracing a request across services far easier.

And there are equally clear-cut cases for saying no:

• When a smaller key is enough. A database that owns its rows can use an auto-increment integer: 4 to 8 bytes instead of 16, naturally sorted, and friendlier to index locality, while UUIDs inflate every secondary index since each stores the primary key.
• When humans handle the ID. Nobody wants to read a support ticket number over the phone, so a short numeric ID serves users better.
• When order matters. Integers show creation order at a glance; if you also want unguessable values, look at UUIDv7, which embeds a timestamp alongside random bits.

The rule of thumb: default to integers while one database owns the identifiers, and switch to UUIDs when values are created in several places, must survive a merge, or must cross a public boundary without leaking information.

FAQ

What does UUID stand for?

UUID stands for Universally Unique Identifier. It is a 128-bit value, normally written as 32 hexadecimal digits in the 8-4-4-4-12 format, that lets software name an object without needing a central authority to issue the number.

How unique is a UUID?

Unique enough to treat as absolute. A random version 4 UUID has 122 random bits, which is about 5.3 undecillion possible values. Generate a billion every second for 70 years and you would still have only a 50 percent chance of one collision.

What is the difference between a UUID and a GUID?

Nothing, in practice. GUID stands for Globally Unique Identifier and is simply the name Microsoft gave to UUIDs. Both terms describe the same 128-bit value, the same 8-4-4-4-12 format, and the same RFC 4122 standard.

Should every database use UUID primary keys?

No. UUIDs shine when rows are created in many places, when databases must be merged, or when IDs appear in public URLs. But they are 16 bytes, enlarge every index, and are hard to read, so a smaller auto-increment key is usually the better default.

Need a fresh identifier right now? Open the free UUID generator: it creates random version 4 UUIDs in your browser, and nothing leaves your device. For more plain-language explainers like this, browse the AITool.red blog.