What Is a UUID?
A UUID, or 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 nobody else will ever produce the same value. Uniqueness without coordination is the property that matters, and it is why UUIDs end up labelling database rows, Bluetooth services and files on your disk alike.
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 digitTwo positions in there are not random. The first digit of the third group is the version, here 4, which tells you which algorithm produced the UUID. The first digit of the fourth group is the variant, and for every UUID you will realistically meet it is 8, 9, a or b. So a “random” v4 UUID actually holds 122 random bits, with 6 pinned by the spec. Generate a few in the UUID Generator and you will see the third group always start with 4.
The versions that matter
| Version | Built from | Use when |
|---|---|---|
| v1 | timestamp + MAC address | legacy systems; mostly avoid |
| v4 | 122 random bits | the general-purpose default |
| v5 | SHA-1 of a namespace + name | you need the same ID every time |
| v7 | Unix timestamp + random bits | database keys; the modern choice |
v1 combines a 100-nanosecond timestamp with the generating machine’s MAC address. It is unique, and 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 instead: hash a namespace and a name with SHA-1, the same digest the Hash Generator computes, and the same inputs always produce the same UUID. That is what you want when two services need to independently compute “the ID for user alice in system X” and agree. v7, added in RFC 9562, puts a millisecond Unix timestamp in the leading 48 bits with randomness after it, so v7 UUIDs sort by creation time.
Will two v4 UUIDs ever collide?
With 122 random bits there are about 5.3 × 1036 possible v4 UUIDs. The birthday paradox puts the danger zone around the square root of that, so you would need roughly 2.7 × 1018 UUIDs before the odds of a single duplicate reach 50%. Generating one billion of them every second gets you there in about 86 years, and even then it is still a coin flip whether one pair collided. Under any realistic workload the collision probability sits far below the probability of a hardware fault or a cosmic-ray bit flip.
That math assumes a properly seeded cryptographic random source, which is the part worth checking. Real-world v4 collisions have happened, and every documented case traces back to a broken or duplicated random number generator: cloned virtual machines seeding identically, bad PRNGs. None of them were bad luck.
UUIDs as database keys
The argument for is straightforward. Any client, service or offline device can mint a key without a round-trip to the database, records created in separate systems merge without renumbering, and an ID is valid before the row is ever inserted, which simplifies distributed writes, retries and event logs enormously.
The argument against is physical rather than logical. B-tree indexes love sequential inserts, where 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. On a large table that is a measurable write and storage penalty.
Fixing exactly that is what v7 is for. Because its leading bits are a timestamp, consecutively created v7 UUIDs come out nearly sequential and their inserts cluster at the end of the index the way an auto-increment column does, 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 the 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 to 8 bytes against 16), faster to index, and human-friendly in a way 3f2b6e0a-... never will be. They carry two costs.
The first is that sequential IDs are guessable. If your invoice lives at /invoices/1052, somebody will try 1053, and the count itself leaks business volume; competitors have estimated order rates from ID gaps. The second is that 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 unguessable, globally unique IDs 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 appears in URLs and API responses. If you just need a handful right now, the UUID Generator produces v4 and v7 UUIDs in bulk, in your browser.