What Is a UUID?

A UUID— Universally Unique Identifier — is a 128-bit value used to label something uniquely, without asking anyone's permission. They look like this:

f47ac10b-58cc-4372-a567-0e02b2c3d479

The remarkable claim baked into the name is that you can generate one on your laptop, someone else can generate one on a server in another country, and the two will never clash — with no coordination between you whatsoever. This guide explains how that works, why it is trustworthy, and when a UUID is the wrong choice.

The problem UUIDs solve

The traditional way to give things unique IDs is a counter: 1, 2, 3, and so on. A database column with auto-increment does this, and it works beautifully — as long as there is exactly one authority handing out numbers.

That assumption collapses in a distributed world. If two servers both hand out ID 42, you have a conflict. If a mobile app must create records offline, it cannot ask the database for the next number. If you merge two databases, their IDs overlap.

UUIDs solve this by making the ID space so absurdly large that you can just pick one at random and be confident nobody else has ever picked the same one. No central authority. No coordination. That is the entire idea.

The format

A UUID is 128 bits, written as 32 hexadecimal digits in five groups separated by hyphens: 8-4-4-4-12.

Two of those digits are not random. The first digit of the third group is the version, and the first digit of the fourth group is the variant. In the example above the version digit is 4, telling you it is a random UUID. That is why so many UUIDs you see have a 4 in that position.

The versions worth knowing

• v4 — random. The one you almost always want. 122 of the 128 bits are randomly generated. Simple, and reveals nothing about where or when it was made.
• v1 — timestamp + MAC address.The original scheme. It has a privacy problem: it embeds the machine's network hardware address and the exact time of creation, both of which can be extracted. Best avoided.
• v5 — name-based (SHA-1). Deterministic: the same input name always produces the same UUID. Useful when you need a stable, reproducible ID derived from something.
• v7 — timestamp + random. The modern hybrid, and increasingly the best default. Random enough to be unguessable, but with a timestamp at the front so the IDs sort chronologically — which solves the database performance problem described below.

Why collisions genuinely never happen

“Random, therefore two could match” is a reasonable instinct. Here is why it is not a practical concern.

A v4 UUID has 122 random bits, giving roughly 5.3 × 10³⁶ possible values. That is 5.3 undecillion.

The relevant maths is the birthday problem, and the usual way of expressing the result is this: you would need to generate around one billion UUIDs per second for about 85 years to have even a 50% chance of a single collision.

Put differently, you are vastly more likely to be hit by a meteorite while reading this sentence than to see a UUID collision. It is not that collisions are impossible in principle — they are impossible in practice, and every serious system relies on that.

One caveat: this holds only if the randomness is cryptographically strong. A UUID generated from a weak or badly-seeded random source can collide, and has. Use a proper generator.

UUID vs. auto-increment: an honest comparison

Auto-increment integers win on:

• Size. 4 or 8 bytes, versus 16 for a UUID — and 36 characters if you store it as text, which many people carelessly do.
• Human friendliness.“Order 1042” is something a support agent can read aloud. A UUID is not.
• Database index performance. See below — this is the big one.

UUIDs win on:

• No coordination. Generate anywhere — client, server, offline — with no round trip.
• Merging data. Combine two databases with zero ID conflicts.
• Not leaking information. This one matters more than people realise. Sequential IDs are an information leak: if your order is #1042, a competitor knows you have had roughly 1,042 orders. Worse, they enable enumeration — an attacker can simply walk /invoice/1, /invoice/2, /invoice/3 and harvest everything that is not properly access-controlled. This is a real and frequent breach pattern. UUIDs cannot be guessed or enumerated.

The database performance trap

This is the one genuine technical downside of random UUIDs, and it catches people at scale.

Databases store primary keys in an index, typically a B-tree, kept in sorted order. With auto-increment IDs, every new row appends neatly to the end of the index. It is efficient, cache-friendly and predictable.

A random v4 UUID lands in a random position in that sorted index every single time. Inserts scatter across the whole structure, causing page splits and thrashing the cache. On a large, write-heavy table this can hurt insert performance substantially.

This is precisely the problem UUIDv7 was created to fix. By putting a timestamp in the leading bits, v7 UUIDs are roughly sequential — new ones sort near the end, like an auto-increment — while the remaining random bits keep them unguessable. You get both properties. If you are choosing a UUID version for a database primary key today, v7 is usually the right answer.

Also: store UUIDs as binary(16), not as a 36-character string. Storing them as text more than doubles the space and slows every comparison.

UUID or GUID?

The same thing. GUID(Globally Unique Identifier) is Microsoft's name for it. The only differences are cosmetic — Microsoft tooling often wraps them in braces and uses uppercase. The 128-bit value is identical.

Common mistakes to avoid

• Using v4 as a primary key on a huge write-heavy table without considering the index cost. Use v7.
• Storing UUIDs as strings when your database has a native UUID or binary type.
• Using a weak random source. This is the only realistic way to cause a collision.
• Using v1and leaking your server's MAC address and creation timestamps.
• Showing UUIDs to users as reference numbers. Nobody can read one over the phone.
• Treating a UUID as a secret. It is unguessable, but it is not an access token. Still check permissions.

Frequently asked questions

Can two UUIDs ever be the same? Mathematically possible, practically never — provided the generator uses strong randomness.

Are UUIDs secure or random enough to be secret? A v4 UUID is unguessable, which is useful. But it is an identifier, not an authorisation. Always enforce access control separately.

Which version should I use? v4 for general purposes. v7 for database primary keys.

Can I shorten a UUID? You can re-encode the same 128 bits in a denser alphabet — Base62 gives a shorter string — but you cannot remove bits without weakening the uniqueness guarantee.

Generate a UUID now

Use our UUID Generator to create v4 UUIDs in your browser, using cryptographically strong randomness — nothing is transmitted. For random numbers rather than identifiers, try the Random Number Generator, and read how random number generators work.