What a UUID actually is
A UUID — Universally Unique Identifier — is a 128-bit number. To keep it readable, those 128 bits are written as 32 hexadecimal digits split into five groups by hyphens, following the 8-4-4-4-12 pattern, for a total of 36 characters:
550e8400-e29b-41d4-a716-446655440000
Microsoft calls the same thing a GUID (Globally Unique Identifier). The name is different but the value is identical: 128 bits in the same hex layout. If you see "GUID" in Windows or .NET code, read it as "UUID".
The point: identity without coordination
The traditional way to give rows unique IDs is an auto-increment integer: the database keeps a counter and hands out 1, 2, 3, and so on. That works beautifully when a single database is the sole authority on what number comes next. It falls apart the moment you have more than one source of IDs — two servers, an offline mobile app, or two datasets you want to merge — because each would independently produce its own "1".
A UUID solves this by being so large and (for the common version) so random that any generator, anywhere, can mint one without asking permission and without realistic risk of duplication. That makes UUIDs ideal for distributed systems, client-generated IDs (the app creates the ID before it ever talks to the server), and merging datasets from different sources without renumbering anything.
The versions
Not all UUIDs are made the same way. The standard defines several versions, each encoding a different strategy in the bits. A version digit sits at a fixed position (the first character of the third group), so you can tell them apart at a glance.
| Version | How it's built | Use it for |
|---|---|---|
| v1 | Timestamp + the machine's MAC address | Legacy; can leak the host and time it was made |
| v3 / v5 | Name hashed with MD5 (v3) or SHA-1 (v5) | Deterministic IDs — same input always yields the same UUID |
| v4 | 122 random bits | The everyday default — a generic unique ID |
| v7 | Unix timestamp + random bits, time-ordered | Database primary keys that index well |
For day-to-day work, v4 is what you almost always want, and it's the default in nearly every library. The newer v7 is worth knowing about: because it puts the time at the front, the IDs sort in roughly creation order, which makes them far friendlier to database indexes (more on that below). The name-based v5 is handy when you need the same input to always map to the same ID. You can generate any of these instantly with the free UUID generator.
How v4 works — and why collisions don't happen
A version 4 UUID is mostly noise from a good random source. Of its 128 bits, 6 are reserved to mark the version and variant; the remaining 122 bits are random. That leaves roughly 2^122 ≈ 5.3 × 10^36 possible values — about five undecillion.
The natural worry is collisions: could two random UUIDs come out identical? The right way to reason about this is the birthday problem, which says collisions become likely much sooner than the raw count suggests. Even so, the numbers here are absurd in our favour. You would need to generate billions of UUIDs per second for decades before reaching even a one-in-a-billion chance of a single duplicate. For any real application — even one creating millions of IDs a day — the probability is so close to zero that it is treated as zero. You do not need a uniqueness check.
8-4-4-4-12 form (36 characters with hyphens). v4 = random, and it's the default you'll reach for unless you have a specific reason not to.UUID vs auto-increment integer
Neither is universally better — they trade different things. The case for UUIDs:
- No coordination needed — any process can create one without touching a shared counter, which is the whole reason they exist.
- Hard to guess or enumerate — sequential integers expose how many records you have and let an attacker walk
/users/1,/users/2, and so on. A random UUID gives nothing away.
The costs:
- Size — 16 bytes versus 4–8 for an integer. Across a large table and its indexes that adds up.
- Not naturally sortable — a v4 UUID has no order, so you can't sort by ID to get creation order (use a timestamp column, or switch to v7).
- Index fragmentation — because v4 values are random, new rows land in random positions in a B-tree index, causing page splits and bloat. This is exactly the problem v7 fixes: its time prefix means new IDs are always "larger", so inserts append cleanly to the end of the index.
When to use one — and when not to
Reach for a UUID when IDs are created in more than one place, when clients need to generate them before syncing, when you're merging data from separate systems, or when an ID will be exposed publicly and shouldn't be guessable. If those IDs are database primary keys, prefer v7 to keep indexing healthy.
Stick with an auto-increment integer when a single database owns all the IDs, storage and index performance are tight, and you don't need unguessable identifiers. There's no shame in a plain integer — it's smaller, faster, and perfectly ordered. The deciding question is almost always: will more than one thing ever generate IDs? If yes, a UUID earns its keep.
If you need a deterministic identifier from some input rather than a random one, a name-based v5 UUID or a plain hash both work — see the hash generator for MD5/SHA digests, and the Base64 encoder if you simply need to make an ID URL-safe rather than unique.
The takeaway
A UUID is just 128 bits dressed up as 36 readable characters, designed so anyone can create one without asking. Use v4 for general uniqueness, v7 when it's a database key, and reach for an integer when a single source can safely own the numbering. Understand that one trade-off and you'll always pick the right ID.
Frequently asked questions
- Is a UUID the same as a GUID?
- Yes — they are the same thing. UUID (Universally Unique Identifier) is the name used in the RFC standards and most languages, while GUID (Globally Unique Identifier) is the term Microsoft uses across Windows and .NET. Both are 128-bit values written in the same 8-4-4-4-12 hex format, so a GUID is just a UUID by another name.
- Can two UUIDs ever collide?
- In theory yes, in practice no. A version 4 UUID has 122 random bits, giving about 5.3 x 10^36 possible values. By the birthday problem, you would need to generate on the order of a billion UUIDs per second for roughly 85 years to reach even a one-in-a-billion chance of a single collision. For any normal application the risk is effectively zero.
- Which UUID version should I use?
- Use version 4 (random) when you just need a unique identifier — it is the default in almost every library. Use version 7 if the IDs will be primary keys in a database, because v7 is time-ordered and indexes far better. Use version 5 only when you need a deterministic ID derived from a name or string.
- Are UUIDs slower than auto-increment integer IDs?
- They use more space — 16 bytes versus 4 to 8 for an integer — and a random v4 UUID can fragment a database index because new rows land in random positions. Auto-increment integers are smaller and naturally ordered. A time-ordered v7 UUID removes most of the indexing penalty while keeping the no-coordination benefit.
This guide is general technical information. Always confirm UUID behaviour against your language's standard library and the relevant RFC for production systems.