What Is a UUID, and Why Does It Matter?
Developer Tools - 3 min read - Published 2026-08-27 - Updated 2026-10-19
A UUID (universally unique identifier) is a 128-bit value used to identify something - a database row, a file, a device, an order - without asking a central authority for the next available number. Any computer can generate one at any time, and it will almost certainly never match a UUID generated anywhere else. Microsoft's name for the same thing is a GUID (globally unique identifier).
What a UUID looks like
UUIDs are usually written as 32 hexadecimal digits in five groups separated by hyphens, 8-4-4-4-12, for 36 characters in total: 3f2504e0-4f89-41d3-9a0c-0305e82c3301. Letters are case-insensitive.
Two positions carry meaning. The first digit of the third group is the version: in the example it's 4, so this is a version 4 UUID. The first digit of the fourth group shows the variant; for standard UUIDs it's 8, 9, a or b. The current specification is RFC 9562 (2024), which replaced the long-standing RFC 4122.
The versions you'll meet
Version 4 is the most common: apart from the six bits that mark the version and variant, all 122 bits are random. It reveals nothing about when or where it was made.
Version 1 combines a timestamp with an identifier for the machine, historically its network card's MAC address. That makes it unique without randomness, but it also reveals when and on which machine it was generated, which is why it fell out of favor.
Version 7, standardized in RFC 9562, starts with a millisecond timestamp and fills the rest with random bits. Version 7 UUIDs generated later sort after earlier ones, which makes them much friendlier as database keys while staying practically unique. Versions 3 and 5 are different: they're derived from a name (such as a URL) by hashing, so the same input always gives the same UUID.
How unlikely is a collision?
With 122 random bits there are about 5.3 × 10^36 possible version 4 UUIDs. By the birthday problem, you would need to generate around 2.7 × 10^18 of them - 2.7 quintillion - before there was even a 50% chance that any two matched. For comparison, generating a billion UUIDs every second, it would take roughly 86 years to reach that point.
In practice, collisions come from bugs, not chance: using a weak random number generator, copying the same UUID into several records, or generating identifiers with a non-standard method. Generate UUIDs with your platform's standard function, which uses a cryptographically secure random source.
UUIDs as database keys
The advantages are real. Records can be created on different servers, in offline mobile apps or in different databases and merged later without ID clashes. IDs don't reveal how many records exist, unlike sequential numbers where order 10452 tells a competitor roughly how many orders you've had. And a client can create the ID before saving, which simplifies some workflows.
The costs: a UUID takes 16 bytes as binary (36 as text) instead of 4 or 8 for an integer, which makes indexes larger. Random version 4 values also arrive in no particular order, so new rows land all over the index rather than at the end, which can slow writes on large tables. Version 7 UUIDs largely solve that, because they're time-ordered. Storing UUIDs in a native UUID or binary column, rather than as text, saves space and speeds up comparisons.
What UUIDs are not
A UUID is an identifier, not a secret. Even random version 4 UUIDs shouldn't be the only thing protecting a private resource, such as a password-reset link; use a purpose-built random token with an expiry, and check permissions on every request. And version 1 and 7 UUIDs contain timestamps that anyone can read, so don't use them where the creation time should stay private.