UUID versions explained: v4, v7, and what the rest are for

What a UUID actually is

A UUID (universally unique identifier) is a 128-bit label written as 36 characters: 32 hexadecimal digits in the pattern 8-4-4-4-12, like 123e4567-e89b-42d3-a456-426614174000. The format is defined by RFC 9562, which replaced the long-standing RFC 4122 in 2024. The point of the standard is in the name: generate an ID anywhere, on any machine, with no coordination, and the odds of two ever matching are negligible.

Not all UUIDs are built the same way, though. The version nibble, a single hex digit, tells you which recipe produced the string.

The versions, one by one

v1: timestamp plus hardware address

The original recipe: a 60-bit timestamp plus the generating machine's MAC address. It sorts by time, but it broadcasts the hardware identity of whatever minted it, which is why most teams dropped it. You will meet v1 in older systems.

v2: DCE security (rare)

A POSIX variant of v1 that trades timestamp bits for a local user or group ID. Rarely seen outside legacy DCE setups. Know it exists; move on.

v3 and v5: hashed from a name

Both take a namespace UUID plus a name and hash them, so the same input always yields the same UUID. v3 uses MD5, v5 uses SHA-1. They are the right choice when you need a stable identifier derived from something meaningful, like a URL or a domain name, rather than a fresh random one.

v4: the random default

122 of 128 bits come from a random source. No structure, no embedded time, nothing to infer. This is the version most people mean when they say UUID, and it remains the safe default for request IDs, API keys, test fixtures and anything where unpredictability is a feature.

v6: v1, reordered

A newer standard that rearranges v1's fields so the timestamp sits at the front, making IDs sort chronologically without leaking the MAC address the way v1 layouts did. Valid per RFC 9562, still uncommon in the wild.

v7: Unix time, sortable

The top 48 bits hold a Unix timestamp in milliseconds, followed by random bits. IDs created later sort after earlier ones, which keeps database indexes happy on insert-heavy tables. If you are choosing a primary key for a new table today, v7 is the one to look at first. Note what it gives away: the creation time, to the millisecond.

v8: custom

A vendor-defined format: the RFC's shape, your payload. Use it only when a specific system or standard demands it.

v4 or v7: which one should you use?

For database primary keys, lean v7: time-ordered IDs land near the end of the index instead of scattering across it, so inserts stay cheap as the table grows. For anything where the value itself should be unguessable, request IDs, tokens, share links, stay with v4, since a v7 ID reveals exactly when it was made.

If you cannot decide, pick v4. It is the default for a reason, and the switch to v7 is only worth it once index behavior on large tables starts to matter. Whichever you choose, use it consistently within a system.