What Is a UUID? Versions, Collisions and When to Use One

Updated July 25, 2026

A UUID — Universally Unique Identifier — is a 128-bit number designed so that anyone, anywhere, can generate one without checking with anyone else, and still be effectively certain no one ever generates the same one. That single property — uniqueness without coordination — is why UUIDs label everything from database rows to Bluetooth services to files on your disk.

What a UUID actually is

The canonical form writes those 128 bits as 32 hexadecimal digits in an 8-4-4-4-12 grouping:

3f2b6e0a-1c4d-4a7e-9b2f-8d1e5c0a7f42
              ^    ^
              |    variant digit (8, 9, a or b)
              version digit

Two positions are not random. The first digit of the third group is the version — here 4 — telling you which algorithm produced the UUID. The first digit of the fourth group is the variant, which for every UUID you will realistically meet is 8, 9, a or b. So a “random” v4 UUID actually contains 122 random bits, with 6 bits pinned by the spec. Generate a few in the UUID Generator and you’ll see the third group always starts with 4.

The versions that matter

v1 combines a 100-nanosecond timestamp with the generating machine’s MAC address. It is genuinely unique, but it leaks: given a v1 UUID you can recover when and on which network card it was made — the Melissa virus author was traced partly this way. v4 is pure randomness and what most libraries hand you by default. v5 is deterministic: hash a namespace and a name (with SHA-1 — the same digest the Hash Generator computes) and the same inputs always yield the same UUID, which is exactly what you want for “the ID for user alice in system X” computed independently by two services. v7, added in RFC 9562, puts a millisecond Unix timestamp in the leading 48 bits and randomness after it, so v7 UUIDs sort by creation time — more on why that matters below.

Will two v4 UUIDs ever collide?

With 122 random bits there are about 5.3 × 10³⁶ possible v4 UUIDs. The birthday paradox says collisions get likely around the square root of that: you would need roughly 2.7 × 10¹⁸ UUIDs before the odds of even one duplicate reach 50%. For perspective, generating one billion UUIDs every second gets you there in about 86 years — and after all that, it is still a coin flip whether a single pair collided. Under any realistic workload the collision probability is so far below the probability of a hardware fault or a cosmic-ray bit flip that it is not the thing to worry about. The honest caveat: this math assumes a properly seeded cryptographic random source. Real-world v4 collisions have happened, and every documented case traces to a broken or duplicated random number generator — cloned virtual machines seeding identically, bad PRNGs — not to bad luck.

UUIDs as database keys

The case for: any client, service or offline device can mint a key without a round-trip to the database, records created in different systems can be merged without renumbering, and an ID is valid before the row is ever inserted — which simplifies distributed writes, retries and event logs enormously.

The case against is physical, not logical. B-tree indexes love sequential inserts: new entries append neatly at the end. Random v4 keys land at arbitrary positions across the index, so inserts touch random pages, caches churn, and pages split — a measurable write and storage penalty on large tables. This is precisely the problem v7 exists to fix: because its leading bits are a timestamp, consecutively created v7 UUIDs are nearly sequential, and inserts cluster at the end of the index like an auto-increment column — while keeping the generate-anywhere property. For a new system in 2026 that wants UUID keys, v7 is the sensible default; reach for v4 when IDs must reveal nothing at all, since a v7 UUID does expose its creation time.

UUID vs auto-increment

Auto-increment integers are smaller (4–8 bytes vs 16), faster to index, and human-friendly in a way 3f2b6e0a-... never will be. But they carry two costs. Sequential IDs are guessable: if your invoice lives at /invoices/1052, someone will try 1053 — an enumeration attack — and the count itself leaks business volume (competitors have literally estimated order rates from ID gaps). And they are single-writer: two databases assigning their own sequences will mint the same numbers, which turns mergers, sharding and offline-first sync into renumbering projects. UUIDs cost 8 extra bytes per key and buy you unguessable, globally unique IDs that any node can create. A common middle path uses both: an internal auto-increment key for join performance, plus a UUID as the public identifier that ever appears in a URL or API.

If you just need a handful right now, the UUID Generator produces v4 and v7 UUIDs in bulk, entirely in your browser.