Pick Your Cut: A Chef’s Guide to GUID Versions
Most developers know one GUID version. They call Guid.NewGuid(), uuid.uuid4() or crypto.randomUUID(), get a random 128-bit value and move on. It works, so the rest of the standard never comes up.
But the spec defines eight versions, plus a nil value. They all use the same 128 bits in different ways, and that changes how the ID sorts, what it reveals and where it fits. Choosing one is closer to picking the right knife than grabbing the nearest tool.
Before you choose, it helps to know how to read a GUID. Then we can walk through the versions that still matter.
The versions at a glance
The versions fall into a few clear groups:
- Time-based: v1, v6 and v7
- Name-based: v3 and v5
- Random: v4
- Custom: v8
- Legacy: v2
- Nil: all zeros
Why v1 and v2 are mostly dead
v1 was the original design. It combines a timestamp with a node identifier, historically the machine’s MAC address. That makes it sortable and easy to generate without coordination, but it also leaks host information into every ID. For public systems, that is a bad trade.
v2 goes further in the wrong direction. It adds POSIX UID or GID data for DCE security contexts and is rarely implemented today. If you run into one, treat it as legacy baggage.
Both versions sort well. Both expose information you usually do not want to expose.
Why v3 and v5 exist
v3 and v5 solve a different problem. They hash a namespace plus a name into a fixed value. Give them the same inputs and they return the same GUID every time. That is useful when you need reproducible IDs without a lookup table.
The difference is the hash. v3 uses MD5, which is broken. v5 uses SHA-1, which is also weakened but still the better choice here. If you need deterministic IDs, use v5.
This version makes sense for stable API IDs, content-addressed records and anything else that should always map the same input to the same identifier.
Why v4 is still the default
v4 spends 122 of its 128 bits on cryptographically secure randomness. No timestamp. No host data. No order. That simplicity is why it became the default in so many languages and frameworks.
With 122 random bits, collision risk stays theoretical for normal use. v4 also keeps no metadata, which makes it the safest choice for tokens, public URLs and external identifiers.
Get BrunoVT1992’s stories in your inbox
Join Medium for free to get updates from this writer.
What it does not give you is sort order.
Why v6, v7 and v8 were added
RFC 9562 added v6, v7 and v8 in 2024 to cover cases v4 never handled well.
v6 is basically v1 with the timestamp bits rearranged so the value sorts correctly as a plain string. It is mainly a migration path for systems already using v1.
v7 is the one most teams should look at. It puts a 48-bit Unix millisecond timestamp first, then fills the rest with randomness. The result sorts by creation time, avoids host data and keeps decentralized generation. For database primary keys, that matters. Random v4 keys scatter inserts across the index and trigger page splits. v7 keys cluster near the end and behave more like auto-increment integers. You also get rough chronological ordering without a separate created_at column.
v7 does depend on a reasonably accurate system clock. If the clock jumps backward, IDs can come out of order. It also exposes creation time, so think twice before using it for public-facing identifiers.
v8 is the escape hatch. The spec leaves the layout to you as long as you set the version and variant correctly. It is flexible, but that does not make it a default choice. Use it only when you have a clear reason.
Nil is not an ID
The nil GUID is all zeros: 00000000-0000-0000-0000-000000000000. It is a sentinel, not an identifier. Use it to mean “no value.” Never generate it as if it were unique.
How to pick the right version
The decision is simple once you strip away the history:
- New database keys, logs and event streams: v7
- User-facing IDs: v4
- Reproducible IDs from the same input: v5
- Migrating an old v1 system that needs ordering: v6
- A custom layout you fully control: v8
- Avoid for new work: v1, v2 and v3
For a deeper side-by-side comparison, the full GUID version breakdown on GUIDsGenerator.com covers the details in one place.
Make it a choice
Same 128 bits, different job. You would not use the same knife for every cut, and you should not use the same identifier everywhere by reflex.
Pick the version on purpose. The default is fine until it quietly is not.
If you enjoyed this post, follow me for more content like this!
Thanks for reading.
— Bruno
