UUID v1, v4, v5 and v7: Which Version Do You Need?
By Junaid Aslam. 4 min read. Updated .
A UUID is a 128-bit identifier, usually written as 32 hex digits in five groups, like 123e4567-e89b-12d3-a456-426614174000. You can create one anywhere, on any machine, with no central counter, and it won't clash with anyone else's.
There are several versions, and they behave differently. Picking the wrong one can leak information or hurt database indexes as the table grows.
The quick comparison
| Version | Built from | Same input, same output? | Good for |
|---|---|---|---|
| v1 | Timestamp plus a node ID (often the MAC address) | No | Legacy systems |
| v3 | MD5 hash of a namespace and a name | Yes | Legacy name-based IDs |
| v4 | Random bits | No | General purpose IDs |
| v5 | SHA-1 hash of a namespace and a name | Yes | Stable IDs from names |
| v7 | Unix millisecond timestamp plus random bits | No | Database primary keys |
v4: the default for most things
Version 4 is 122 bits of randomness (six bits are reserved to mark the version and variant). It's what you get from crypto.randomUUID() in browsers and Node, and from gen_random_uuid() in PostgreSQL. It reveals nothing about when or where it was made.
Collisions aren't something to lose sleep over. You'd need to generate roughly 2.7 quintillion v4 UUIDs before the odds of even one duplicate reach 50%. A duplicate in practice usually means a bad random number generator.
The catch with v4 and databases
Random IDs land all over the place. If you use them as a primary key in a table with a B-tree index, every insert goes to a random spot in the index. That causes page splits, fragmentation, and a working set that no longer fits in memory as the table grows. On small tables you'll never notice. On tens of millions of rows, you might.
v7: time-ordered, and usually the better key
Version 7 was standardized in RFC 9562 in 2024. The first 48 bits are a Unix timestamp in milliseconds. The rest is random. Because the timestamp comes first, new IDs sort after older ones, so inserts land near the end of the index like an auto-increment column would. You still get an ID you can generate anywhere without coordination.
- Pro: much friendlier to database indexes than v4.
- Pro: you can sort by ID to get rough creation order.
- Con: it leaks the creation time to anyone who has the ID. If that's sensitive (say, a user ID that shouldn't reveal signup time), use v4.
Newer database versions have started adding native support. PostgreSQL 18, for example, includes a uuidv7() function. Check what your own database and driver offer before you write your own.
v1: mostly a history lesson
Version 1 combines a 100-nanosecond timestamp with a node identifier that was traditionally the machine's MAC address. That means a v1 UUID can reveal when and roughly where it was created. Modern libraries usually substitute a random node ID to avoid that. For new projects, v7 gives you the time-ordering benefit without the baggage.
v3 and v5: same name, same UUID
These two aren't random at all. You give them a namespace (another UUID) and a name (any string), and they hash the pair. The result is deterministic. Run it a hundred times and you get the same UUID every time.
Using the standard DNS namespace and the name example.com, you get:
v5: cfbff0d1-9375-5685-968c-48ce8b15ae17
v3: 9073926b-929f-31c2-abc9-fad77ae3e8ebv5 uses SHA-1 and v3 uses MD5. Since both hashes are only used to spread names out (not to protect anything), the known collision weaknesses don't matter much here. Still, prefer v5 for anything new. Use v3 only when you have to match an older system.
Say two systems both need an ID for the same customer email, and they don't share a database. If both compute v5 with the same namespace and the same email, they'll independently arrive at the same ID. You can also import the same data twice without creating duplicates, because the IDs match.
Example.com and example.com produce different UUIDs. Normalize your names (trim, lowercase) before hashing, or you'll get mismatches that are painful to debug.What UUIDs are not
- Not secrets. A v4 UUID has plenty of randomness, but the spec doesn't promise it's unguessable. Use a proper random token generator for API keys and session tokens.
- Not sequential. Unless you use v7 or v1, don't assume any order.
- Not short. 36 characters with hyphens. If IDs appear in URLs a lot, consider whether a shorter ID fits better.
A simple way to choose
- Need the same ID every time from the same input? Use v5.
- Using it as a database primary key at scale? Use v7.
- Creation time must stay private, or you just need a unique ID? Use v4.
- Working with an older system that expects v1 or v3? Match it, and plan to move on.
The UUID Generator makes all five versions, including bulk mode and namespace presets for v3 and v5, so you can compare the output side by side.