UUID Versions Explained: v1 to v8 Compared

Quick Comparison

Version 1: Time and Node

Version 1 combines a 60-bit timestamp (100-nanosecond intervals since 15 October 1582), a clock sequence to handle clock changes, and a 48-bit node field, originally the machine's MAC address. It's unique by construction but leaks when and where it was created, and its timestamp is stored low bits first, so v1 values don't sort by time. UUID v1 and MAC address privacy covers the privacy issue.

Version 2: DCE Security

Version 2 replaces part of the v1 timestamp with a local user or group ID for DCE security. It's barely used, and RFC 9562 doesn't detail its layout; most libraries don't generate it.

Versions 3 and 5: Name-Based

These hash a namespace UUID and a name (such as a URL or domain) to produce a UUID: MD5 for v3, SHA-1 for v5. The same inputs always give the same output, which is useful for stable IDs derived from existing keys. v5 is preferred over v3. UUID v3 vs v5 explains how they work and their limits.

Version 4: Random

122 random bits plus version and variant. Simple, private and universally supported, but random keys scatter across database indexes. What is UUID v4 covers it in depth.

Version 6: Sortable v1

Version 6 takes v1's timestamp and stores it most significant bits first, so values sort by creation time. It still includes a clock sequence and node. RFC 9562 says systems not tied to v1 should use v7 instead; v6 exists mainly to help v1-based systems move to sortable IDs.

Version 7: Unix Time and Random

A 48-bit Unix timestamp in milliseconds, followed by random (or counter plus random) bits. Time-ordered, index-friendly and free of hardware identifiers. It's the recommended version for new systems needing sortable IDs. See what is UUID v7.

Version 8: Custom

Version 8 reserves only the version and variant bits and lets implementers define the other 122 bits, for example to embed a shard ID or use a different hash. Uniqueness depends entirely on the custom design, and only the creator knows how to interpret it.

Special Values

The nil UUID (all zeros) and max UUID (all ones) aren't versions; they're special values with their own rules. Nil UUID and max UUID explains them.

Which Version Should You Use?

There's no single best UUID version; the right one depends on what the ID needs to do. For most new applications the answer is v4 or v7:

• Random ID, no ordering needed: v4.
• Database primary key or time-sortable ID: v7.
• Same input must always produce the same ID: v5.
• Compatibility with existing systems: whatever they already use (often v1 or v4).
• Avoid v1 for new public IDs because of privacy, and v3 when v5 is available.

If you're choosing between the two most common options, UUID v4 vs UUID v7 compares them for database keys in more detail.

Identifying and Generating Versions

To find out which version a UUID is and what's inside it, paste it into the UUID decoder. It reports the version and variant, and for v1, v6 and v7 the embedded timestamp, plus the clock sequence and node for v1 and v6. To generate examples of each, the GUID generator supports versions 1, 3, 4, 5, 6 and 7, and the UUID validator checks lists of values in bulk.

Summary

Eight versions, three practical choices: v4 for random, v7 for time-ordered, v5 for deterministic. Use the 13th hex digit to tell them apart, and avoid v1 for new public identifiers.