UUID Versions Explained: v1, v3, v4, v5, and v7

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value designed to be unique across space and time without requiring a central registration authority. UUIDs are standardized by RFC 9562 (which superseded the original RFC 4122 in 2024) and are used throughout software engineering for database primary keys, distributed system identifiers, session tokens, correlation IDs, and more.

Every UUID is 128 bits long, represented as 32 hexadecimal digits displayed in five groups separated by hyphens in the canonical format: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M nibble indicates the UUID version (1-7), and the top bits of the N nibble indicate the variant (typically 10 for RFC 9562 UUIDs).

There are multiple UUID versions, each with a different strategy for achieving uniqueness. Understanding these differences is critical for choosing the right version for your use case.

UUID v1: Timestamp + MAC Address

UUID v1 was one of the original versions defined in RFC 4122. It combines a 60-bit timestamp (measured in 100-nanosecond intervals since October 15, 1582) with the 48-bit MAC address of the generating machine. A 14-bit clock sequence provides additional uniqueness when the timestamp might repeat, such as after a system reboot or if the clock is set backward.

The key advantage of v1 is that UUIDs generated on the same machine are naturally time-ordered. Because the timestamp is embedded, you can extract the exact creation time from any v1 UUID. This makes v1 useful for scenarios where temporal ordering is important and the generator identity (MAC address) is not sensitive.

However, v1 has a significant privacy concern: the embedded MAC address reveals the hardware identity of the generating machine. This can be used to track or fingerprint devices. Many modern systems either randomize the MAC address in v1 UUIDs or avoid v1 entirely in favor of v4 or v7.

UUID v3 and v5: Namespace-Based (Deterministic)

UUID v3 and v5 are fundamentally different from other versions because they are deterministic: given the same namespace and name, they always produce the same UUID. This makes them ideal for scenarios where you need a stable identifier derived from existing data.

UUID v3 uses MD5 hashing, while v5 uses SHA-1 hashing. Both take two inputs: a namespace UUID (predefined namespaces exist for DNS, URLs, OIDs, and X.500 distinguished names) and a name string. The hash of the concatenated namespace and name is truncated and formatted as a UUID.

// Conceptual example of v5 generation
namespace = UUID("6ba7b810-9dad-11d1-80b4-00c04fd430c8")  // DNS namespace
name = "example.com"
hash = SHA1(namespace + name)
uuid_v5 = formatAsUUID(hash, version=5)

Because v3 uses MD5 (which has known collision vulnerabilities) and v5 uses SHA-1 (also deprecated for security purposes), neither version should be used for security-sensitive applications. However, they remain perfectly suitable for generating stable identifiers from names. UUID v5 is preferred over v3 since SHA-1 is stronger than MD5 for this purpose.

Common use cases include generating consistent identifiers from DNS names, URLs, or other natural keys. If you need the same input to always produce the same UUID, v3 or v5 is the right choice. For related hashing concepts, see our Hash Generator tool.

UUID v4: Random

UUID v4 is the most widely used version today. It generates UUIDs using 122 bits of random data (6 bits are reserved for version and variant fields). With 2 to the power of 122 possible values (approximately 5.3 times 10 to the power of 36), the probability of generating a duplicate is astronomically small.

The simplicity of v4 is its greatest strength: no timestamp, no MAC address, no state to manage. Every UUID is independent, making v4 trivially parallelizable across machines, processes, and threads. There is no information leakage about when or where the UUID was generated.

The collision probability for v4 follows the birthday problem. To have a 50% chance of a single collision, you would need to generate approximately 2.71 times 10 to the power of 18 UUIDs (2.71 quintillion). For most applications, the risk of collision is effectively zero.

The only downside of v4 is that UUIDs are randomly distributed, which means they do not sort chronologically and can cause B-tree fragmentation when used as database primary keys. This is exactly the problem that UUID v7 was designed to solve.

UUID v7: Timestamp-Ordered (The New Standard)

UUID v7, introduced in RFC 9562 (May 2024), is the newest version and was specifically designed to address the database performance problems of random UUIDs. It encodes a 48-bit Unix timestamp in milliseconds in the most significant bits, followed by random data in the remaining bits.

Because the timestamp occupies the leading bits, v7 UUIDs sort in chronological order when compared lexicographically. This is a critical property for database primary keys: sequential inserts into a B-tree index are dramatically faster than random inserts because they always append to the end of the tree rather than causing page splits throughout the structure.

UUID v7 offers the best of both worlds: the temporal ordering benefits of v1 without the MAC address privacy concern, and the simplicity of v4 with dramatically better database performance. The timestamp can be extracted from any v7 UUID, which is useful for debugging and auditing. Try extracting timestamps from UUIDs with our UUID Generator tool, and see how v7 timestamps relate to Unix epoch time with our Epoch Converter.

Which Version Should You Choose?

Choosing the right UUID version depends on your specific requirements. Here is a practical decision guide:

• Need a general-purpose unique ID with no information leakage? Use UUID v4. It is the default choice for most applications, APIs, and distributed systems.
• Using UUIDs as database primary keys? Use UUID v7. The timestamp ordering eliminates B-tree fragmentation and significantly improves insert and range query performance.
• Need a deterministic ID from a name or URL? Use UUID v5. Given the same namespace and name, you always get the same UUID. This is useful for idempotent operations and content-addressed identifiers.
• Working with legacy systems that require v1? Use UUID v1, but consider randomizing the MAC address portion to avoid privacy leakage.
• Need URL-safe, shorter identifiers? Consider alternatives like NanoID or ULID. See our comparison of UUID vs ULID vs NanoID.

UUID Regex Pattern

When working with UUIDs in your code, you often need to validate or match UUID strings. The standard regex pattern for a UUID is:

// Matches any valid UUID (versions 1-7)
/^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i

// Version-specific (v4 only)
/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i

You can test these patterns with our Regex Tester tool.

Try It Yourself

The best way to understand UUID versions is to generate them and compare. Use our UUID Generator to create UUIDs in v1, v4, and v7, then paste them into the Validate tab to see the internal structure, extracted timestamps, version bits, and variant fields. The Collision tab lets you explore the birthday problem probability for each version.