The eight versions in 30 seconds
RFC 9562 (Dec 2024) defines UUID versions 1-8. Five are widely used; three (v3, v5, v8) are niche.
| Version | Source | Sortable? | Use it? |
|---|---|---|---|
| v1 | timestamp + MAC address | By time, sort of | No - leaks the MAC |
| v3 | MD5 of namespace+name | No | Niche (deterministic IDs) |
| v4 | 122 bits of randomness | No | Yes for non-DB-key cases |
| v5 | SHA-1 of namespace+name | No | Like v3 but SHA-1 instead of MD5 |
| v6 | v1 reordered to be sortable | Yes | Skip - v7 is better |
| v7 | 48-bit unix-ms + 74 random | Yes | Yes - default for new DB keys |
| v8 | Custom (defined by you) | Maybe | Niche (custom embedding) |
Why v7 is the right default
v4 was the right answer for fifteen years. It's simple, has 2^122 possible values (collision practically impossible), and cryptographically random - predictable only if your RNG is broken.
The downside: v4 IDs are not sortable. They have no temporal structure. When you use v4 as a primary key in an indexed database table, every insert lands at a random spot in the B-tree. The pages that hold the index split, repaginate, and fragment continuously. On large write-heavy tables this is measurable: insert latency degrades over time, page caches evict more often, and replication latency rises.
v7 fixes this. The first 48 bits of a v7 UUID are a Unix millisecond timestamp, big-endian. The remaining 74 bits are random. So v7s sort by creation time naturally. New rows append to the right of the B-tree (the "hottest" page is always the most recent). Inserts stay fast as the table grows. Retain the collision resistance of v4 (74 bits of entropy is still 2^74 ≈ 1.9×10²² values per millisecond).
Cassandra, Postgres, MySQL all benefit from this when v7 is used as a clustered/primary key. SQLite and DynamoDB benefit similarly.
When v4 still wins
- You don't want sequence leakage. v7 IDs reveal when they were created. If that's confidential (e.g. consecutive customer IDs leak signup velocity to competitors), use v4.
- You're not using it as a database key. Session tokens, file names, ephemeral handles - sortability doesn't help. Just use v4.
- Your database doesn't care about insertion order. Hash-based key-value stores don't have B-trees that need to be balanced. UUID sortability is irrelevant.
v3 and v5 - namespace UUIDs
v3 (MD5) and v5 (SHA-1) deterministically hash a namespace UUID + a name string into a UUID. Useful when you need stable IDs for things that have natural names: v5(DNS, "example.com") == v5(DNS, "example.com") always. Use v5 over v3 (MD5 is broken). Use them only when you actually need the determinism - otherwise prefer v4 or v7.
JustKit's UUID generator
The JustKit UUID generator supports v4 and v7 with bulk generation up to 1000 at a time. v4 uses crypto.randomUUID() where available (Chrome 92+, Node 14+) and falls back to a manual implementation using crypto.getRandomValues. v7 is always implemented manually since browser support is still rolling out.