Understanding UUID Versions: v1, v4, and v7 Explained

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit number used to identify information in computer systems. UUIDs are standardized by RFC 4122 and are designed to be unique across both space and time without requiring a central registration authority.

A UUID looks like this: 550e8400-e29b-41d4-a716-446655440000. It consists of 32 hexadecimal digits displayed in five groups separated by hyphens, following the pattern 8-4-4-4-12.

UUIDs are used everywhere in modern software development: database primary keys, API request identifiers, session tokens, file naming, distributed systems, and message queue deduplication. If you have ever worked with databases, microservices, or REST APIs, you have almost certainly encountered UUIDs.

UUID v1: Timestamp + MAC Address

UUID version 1 generates identifiers using a combination of the current timestamp and the MAC address of the computer generating the UUID. This means every v1 UUID encodes when and where it was created.

How UUID v1 Works

The 128 bits of a v1 UUID are structured as follows:

• 60 bits for the timestamp (measured in 100-nanosecond intervals since October 15, 1582)
• 4 bits for the version number (always 1)
• 2 bits for the variant (always 10 in binary for RFC 4122)
• 14 bits for the clock sequence (prevents duplicates if the clock is set back)
• 48 bits for the node identifier (usually the MAC address)

When to Use UUID v1

UUID v1 is useful when you need time-ordered identifiers and can tolerate exposing the generating machine's identity. Common use cases include event logging, audit trails, and systems where chronological ordering matters.

Privacy Concerns

The major downside of UUID v1 is that it exposes the MAC address of the generating machine. In security-sensitive applications, this can leak information about your infrastructure. For this reason, many developers prefer UUID v4 or the newer UUID v7.

UUID v4: Pure Randomness

UUID version 4 is the most widely used UUID format. Unlike v1, it does not encode any meaningful information. Instead, it is generated entirely from random (or pseudo-random) numbers.

How UUID v4 Works

A v4 UUID uses 122 bits of randomness with 6 bits reserved for version and variant information:

• 122 bits of cryptographically secure random data
• 4 bits for the version identifier (always 4)
• 2 bits for the variant (always 10 in binary)

The probability of generating two identical v4 UUIDs is astronomically small. You would need to generate approximately 2.71 quintillion UUIDs before having a 50% chance of a single collision. To put that in perspective, if you generated one billion UUIDs per second, it would take about 85 years to reach a 50% collision probability.

When to Use UUID v4

UUID v4 is the go-to choice for most applications. Use it when you need unique identifiers but do not require time ordering or any encoded metadata. It is perfect for database primary keys, API tokens, file identifiers, and any scenario where unpredictability is a feature.

UUID v7: The Best of Both Worlds

UUID version 7 is a relatively new addition, proposed in the new UUID format specification. It combines the time-ordering benefits of v1 with the privacy of v4, making it an increasingly popular choice for modern applications.

How UUID v7 Works

A v7 UUID uses a Unix timestamp in milliseconds combined with random data:

• 48 bits for the Unix timestamp in milliseconds (supports dates up to the year 10889)
• 4 bits for the version number (always 7)
• 12 bits of random data
• 2 bits for the variant
• 62 bits of additional random data

Because the most significant bits contain the timestamp, v7 UUIDs are naturally sortable in chronological order. This is a huge advantage for database indexing, where random UUIDs (v4) can cause index fragmentation and slower insert performance.

When to Use UUID v7

UUID v7 is the recommended choice for new projects that need both uniqueness and time ordering. It is ideal for:

• Database primary keys — sortable UUIDs maintain B-tree index efficiency
• Distributed systems — no coordination needed between nodes
• Event sourcing — events are naturally ordered by creation time
• Message queues — messages can be sorted without additional metadata
• Logging and analytics — log entries are inherently time-stamped

Comparison: v1 vs v4 vs v7

UUIDs in Database Design

One of the most common uses for UUIDs is as database primary keys. However, choosing the right version has significant performance implications.

With UUID v4, the random nature causes new rows to be inserted at random positions in the B-tree index. This leads to page splits, increased I/O, and index fragmentation. For write-heavy workloads, this can reduce insert performance by 2-5x compared to sequential keys.

UUID v7 solves this problem elegantly. Because the timestamp occupies the most significant bits, new UUIDs are always greater than older ones. This means inserts always append to the end of the B-tree, just like an auto-increment integer — but with all the benefits of a UUID (no coordination, globally unique, no information leakage about row count).

If you work with JSON data in your API responses, you have likely seen UUIDs used as resource identifiers. Using v7 means your API responses will have naturally sorted IDs, making pagination and cursor-based queries more efficient.

Other UUID Versions

UUID v3 and v5: Name-Based UUIDs

Versions 3 and 5 generate UUIDs from a namespace and a name using MD5 (v3) or SHA-1 (v5) hashing. Given the same namespace and name, they always produce the same UUID. These are useful for generating deterministic identifiers from known data, such as creating consistent IDs from URLs or domain names.

Nil UUID and Max UUID

The nil UUID (00000000-0000-0000-0000-000000000000) represents an empty or missing identifier. The max UUID (ffffffff-ffff-ffff-ffff-ffffffffffff) represents the maximum possible value. Both are useful as sentinel values in code.

Best Practices for Using UUIDs

1. Use UUID v7 for new projects — It offers the best combination of uniqueness, sortability, and privacy. If your language or framework does not support v7 yet, v4 remains an excellent fallback.
2. Always use cryptographic randomness — Never use Math.random() for UUID generation. Use crypto.getRandomValues() in browsers or crypto.randomBytes() in Node.js.
3. Store UUIDs as binary in databases — A UUID stored as BINARY(16) uses 16 bytes, while the string representation uses 36 bytes. For large tables, this difference matters.
4. Consider the tradeoffs — UUIDs are 4x larger than 32-bit integers. For small datasets or embedded systems, auto-increment integers may be more appropriate.
5. Validate UUID format — When accepting UUIDs from user input, always validate the format. Our Regex Tester can help you build and test UUID validation patterns like ^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$.
6. Use UUIDs in URLs carefully — UUIDs in URLs should be properly encoded and lowercased for consistency. If your URLs need to be shorter, consider using only the first 8 characters (with acceptance of higher collision risk) or Base64 encoding the binary form.

Frequently Asked Questions

Conclusion

UUIDs are a fundamental building block of modern distributed systems. While UUID v4 has been the default choice for years due to its simplicity and wide support, UUID v7 is quickly becoming the recommended standard for applications that use databases or need time-ordered identifiers.

The key takeaway: use v7 if you can, v4 if you must, and v1 only if you need MAC-based identification. Avoid v3 and v5 unless you specifically need deterministic, name-based identifiers.

Ready to generate UUIDs for your project? Try our free UUID Generator — it supports all versions, bulk generation, and runs entirely in your browser with no data stored on our servers.