Every UUID Version, and Which One You Want

RFC 9562 defines eight UUID versions, numbered 1 through 8. Four are worth reaching for in new code: v4 for a random ID, v5 for one that has to reproduce identically from the same input, v7 for one that sorts by creation time, and v8 when you want to define the layout yourself. The other four exist mostly to read UUIDs some other system already minted.

Which UUID version should you use?

Pick by what the ID has to do, not by habit.

• Use v4 when you need a unique ID and don't care how it sorts. Generate a UUID v4.
• Use v5 when the same input has to produce the same UUID every time, so two systems can agree on an ID without asking each other first.
• Use v7 when the ID is a primary key and you want new rows to land at the end of the index instead of scattered through it. Generate a UUID v7.
• Use v8 when none of the above fit and you want to pack your own fields into a UUID-shaped value.

None of the eight are a good password reset token or session id. v1, v2 and v6 hand over a machine-derived node field, and v7's leading bits are a readable timestamp. Every version generates free, in your browser, at the UUID generator.

What are all eight UUID versions?

Every version is still 128 bits; what differs is where those bits come from.

RFC 4122 is obsolete: RFC 9562 replaced it in May 2024 and is the citation to use for anything structural.

Where do the version and variant bits live in a UUID?

Every UUID spends the same six bits on bookkeeping: 4 bits for the version, at offset 48, and 2 bits for the variant, at offset 64. That's defined in RFC 9562 §4.2 for the version and §4.1 for the variant, and it's why a v4 UUID carries 122 bits of randomness instead of 128: 4 bits announce it's version 4, and 2 more announce the fixed 10 pattern of the RFC 9562 variant. A v7 spends the same six bits on the same job, which is why it has 74 random bits left after its 48-bit timestamp rather than 80.

Switch the format below to see where every other version puts its own version and variant nibbles.

When should you use UUID v4?

UUID v4 is the default when you have no reason to want anything else: 122 bits from a CSPRNG, with nothing encoded and nothing to leak. Generate a UUID v4 and every bit below the version and variant markers comes from crypto.getRandomValues or your language's equivalent. Because nothing is derived from an input, two v4s minted a millisecond apart on the same machine share nothing but their length.

When should you use UUID v5?

UUID v5 is deterministic: hash a namespace and a name once, and any process that hashes the same two values gets the same UUID back, with no lookup and no coordination. RFC 9562 §5.5 defines it as a truncated SHA-1 digest, and §6.6 lists the pre-defined namespace UUIDs for DNS names, URLs, OIDs and distinguished names. That makes it useful for turning an existing key, like an email address or a URL, into a stable UUID two independent services can each recompute and agree on. Generate a UUID v5. v3 does the same job with MD5, which has known collision weaknesses; new code should use v5 and treat v3 as something you read, not mint.

When should you use UUID v7?

UUID v7 is the one to reach for when the UUID is a database primary key, because its first 48 bits are a Unix millisecond timestamp, so rows inserted later sort after rows inserted earlier. Generate a UUID v7. Support isn't universal yet, so check your stack's version before you assume it's built in.

Older versions of all four need a third-party library or an application-side implementation instead.

When should you use UUID v8?

UUID v8 fixes only the version and variant bits and leaves the other 122 for you to define, so it's the version to reach for when none of the other seven fit the layout you already have. RFC 9562 §5.8 gives you the version nibble at offset 48 and the variant bits at offset 64 and nothing else, which is why v8 usually shows up as a way to keep an existing internal id UUID-shaped: packing a tenant id, a shard number, or a truncated hash into those 122 bits so it fits a column typed uuid. Generate a UUID v8 on this site fills them with randomness by default, since that's the only layout that makes sense without knowing your schema; a real v8 in production usually encodes something meaningful instead.

What about UUID v1, v2, v3, and v6?

These four exist mostly to read or migrate values another system already produced, not to mint new ones.

• v1 and v6 both carry a 60-bit timestamp and a 48-bit node field that may be a real MAC address. v6 is v1 with those fields reordered so the text form sorts; RFC 9562 added it in 2024 for teams already generating v1s who want the same node and clock design but a sortable text form. UUID v1 · UUID v6.
• v3 hashes a namespace and a name with MD5, which has known weaknesses. UUID v5 does the same job with SHA-1, so v3 is mostly for reading UUIDs an older system already minted. UUID v3.
• v2 is DCE Security. RFC 9562's version table lists it as "Reserved for DCE Security version, with embedded POSIX UUIDs", and §5.2 says outright that "the definition of these UUIDs is outside the scope of this specification." It's a real version number with no current spec behind it. UUID v2.

How do you read a UUID you were handed?

Look at the first character of the third group: xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx, where V is the version number, unless the UUID is all zeros or all ones. Paste the example below and the third group starts with 7, which decodes to a v7 UUID minted at 2024-05-07T00:00:00.000Z, RFC 9562's own publication month, with 09C1D4E5B6F7A8C9 of randomness after the timestamp.

This runs the same decoder as the universal decoder, which reads UUIDs alongside ULID, KSUID, TypeID, ObjectID and Snowflake entirely in your browser; nothing you paste is sent anywhere.

What did RFC 9562 change?

RFC 9562, published in May 2024, obsoletes RFC 4122 outright and adds three things the old spec didn't have: version 6, version 7, version 8, and formal names for the nil and max UUIDs. Sections 5.6 through 5.8 define v6 through v8; sections 5.9 and 5.10 give the all-zero UUID (00000000-0000-0000-0000-000000000000) and the all-one UUID (ffffffff-ffff-ffff-ffff-ffffffffffff) their own names, rather than leaving them as UUIDs with an unassigned version nibble. Our own decoder checks for both forms before it tries to read a version out of them, because a nil or max UUID doesn't actually have one. Almost every UUID explainer still online predates May 2024 and describes a five-version world; RFC 9562 is the citation for anything about UUID structure now.