What Is a UUID, and Why Is It Everywhere?

Open almost any modern app's database or API and you'll find long strings like f47ac10b-58cc-4372-a567-0e02b2c3d479 used as identifiers. These are UUIDs, and they solve a surprisingly deep problem: how do you give millions of things unique names when no single authority hands out the numbers? This guide explains what a UUID is, why it works, and when you'd want one.

The problem UUIDs solve

Imagine you're building an app. Every user, order and photo needs a unique ID. The obvious approach is counting: user 1, user 2, user 3. This works fine when one database assigns the numbers. But modern systems are distributed — data is created on phones that are offline, on multiple servers at once, across different data centres. If two servers both hand out "order 500" at the same moment, you have a collision and a corrupted system.

You could have every server ask a central counter for the next number, but that central point becomes a bottleneck and a single point of failure. What you really want is a way for anyone, anywhere, to generate an identifier that is essentially guaranteed to be unique — without coordinating with anyone else. That's exactly what a UUID provides.

What a UUID looks like

A UUID (Universally Unique Identifier — also called a GUID in Microsoft's world) is a 128-bit value, usually written as 32 hexadecimal characters split into five groups by hyphens, like f47ac10b-58cc-4372-a567-0e02b2c3d479. That's a fixed, recognisable shape. The hyphens are just for readability; the value is the 128 bits.

Why they're practically unique

Here's the part that feels like magic. The most common type, version 4, is almost entirely random — 122 of its 128 bits are random. The number of possible version-4 UUIDs is around 5 followed by 36 zeros. That quantity is so vast it's hard to convey. A common way to put it: you would have to generate billions of UUIDs every second for around a hundred years before you'd have even a tiny chance of a single collision.

So UUIDs aren't guaranteed unique in a mathematical sense — two random ones could theoretically match — but the probability is so astronomically small that, in practice, everyone treats them as unique. That's the trade the design makes: give up an absolute guarantee in exchange for the ability to generate IDs anywhere, instantly, with no coordination.

The different versions

Not all UUIDs are made the same way, and the "version" (the digit at the start of the third group) tells you how:

• Version 4 is random. It's the everyday default — simple, needs no inputs, and is what our UUID generator produces. If you just need a unique ID, this is almost always the right choice.
• Version 1 is based on the time and the device's network address. It's sortable by creation time but can leak information about where and when it was made.
• Versions 3 and 5 are derived from a name using a hash, so the same input always yields the same UUID — useful when you want a deterministic ID for a known thing.
• Newer versions (6 and 7) combine a timestamp with randomness to be both sortable and collision-resistant, which is increasingly popular for database keys.

When to use one

Reach for a UUID whenever you need an identifier and can't (or don't want to) rely on a central counter:

• Primary keys in databases that sync across devices or servers.
• IDs generated on the client before the server has seen the record — handy for offline-first apps.
• File names or upload keys that must never clash.
• Correlation IDs to trace a single request across many services.

When not to use one: UUIDs are long and not human-friendly, so they're a poor fit for anything a person has to read out, type, or remember — order confirmation codes, coupon codes, URLs meant to be shared verbally. There, a shorter, friendlier code is better even if it needs a central generator.

UUIDs are not secrets

One important caution: a UUID being hard to guess does not make it a security token. A version-4 UUID is random enough that it's impractical to guess, so people sometimes use one as an unguessable link. That can be acceptable for low-stakes "secret URLs", but UUIDs aren't designed as credentials — they can end up in logs, browser history and analytics. For anything that genuinely needs to be secret, use a purpose-built secret or token, and a strong password generator for passwords.

Key takeaways

• A UUID is a 128-bit identifier that anyone can generate independently, with practically no chance of collision.
• Version 4 (random) is the everyday default; other versions add time-ordering or determinism.
• Use them for distributed IDs and file names; avoid them where a human must read or type the value.
• They're unguessable but not secrets — don't treat a UUID as a security token.