What a UUID is, the versions that matter, and whether collisions can happen

A UUID looks like 3f2504e0-4f89-11d3-9a0c-0305e82c3301: 32 hexadecimal digits, five groups, 128 bits. It exists so that any computer anywhere can mint an identifier without asking a central authority and be confident nobody else will ever produce the same one. The UUID generator makes them in the browser; this guide explains the versions and the one question everyone asks.

What a UUID is

Universally unique identifiers (also GUIDs in Microsoft's world) were standardised from Apollo Computer's 1980s network system, then in RFC 4122 (2005), replaced in 2024 by RFC 9562, which added new versions. All are 128 bits; the hyphenated hex form is just the standard way to write them. A few bits are reserved: four for the version number (the first digit of the third group) and two or three for the variant (the first digit of the fourth group, which is why it is always 8, 9, a or b in modern UUIDs).

The versions

• Version 1 — a timestamp plus the machine's MAC address. Unique by construction but leaks when and where it was made; largely superseded.
• Version 3 and 5 — a hash (MD5 or SHA-1) of a namespace and a name, so the same input always gives the same UUID. Useful for deriving stable IDs from URLs or names.
• Version 4 — 122 random bits. The common one; what most generators, databases and languages produce by default.
• Version 7 (RFC 9562) — a millisecond timestamp in the high bits followed by random bits. Sortable by creation time, which fixes the database problem below while keeping uniqueness.

Version 2 exists for legacy DCE security and version 6 reorders v1 for sortability; neither is common.

Can two UUIDs collide?

A v4 UUID has 2¹²² possible values — about 5.3 × 10³⁶. The birthday bound says you'd need to generate roughly 2⁶¹ of them (2.3 quintillion) for a 50% chance of a single duplicate; at a billion per second that takes 73 years. For any real system the probability is far below that of hardware failure, cosmic-ray bit flips or a bug. The honest caveat is the random source: a generator seeded badly (the same seed on cloned virtual machines, a weak library) can repeat. Browsers use the operating system's cryptographic randomness (crypto.randomUUID), which is fine. How random is a random number generator? covers what "random" means in software.

UUIDs as database keys

UUIDs make excellent identifiers for records created on many machines, exposed in URLs (no guessable sequence, unlike /user/1042), or merged from several sources. As a primary key in a B-tree index, a v4 has a cost: random values insert all over the index rather than at the end, fragmenting it and slowing writes on large tables — the reason v7 was designed, and why databases offer sequential alternatives (ULID, Snowflake IDs). Store UUIDs as 16 bytes, not as a 36-character string, if the database supports it. For a small table none of this matters.

When to use one

Use a UUID when uniqueness across systems matters, when IDs are generated before reaching the database, or when exposing an ID shouldn't reveal how many records exist. Use a sequential integer when a single database owns the table and IDs stay internal. Use v5 when the same input should always map to the same ID. And don't use a UUID as a secret: it's unguessable, but it's not a password, and it appears in logs and URLs. The password generator makes secrets; the hash generator shows the hashing behind v5.