How to Generate UUIDs: v1, v4, and v7 Explained

If you have ever built an application that needs unique identifiers for records, users, transactions, or any other entities, you have likely encountered UUIDs. These 128-bit identifiers are designed to be globally unique without requiring a central authority. But there are multiple versions of UUIDs, each with different characteristics. This guide explains the three most commonly used versions and helps you choose the right one for your project.

1. What Is a UUID?

UUID stands for Universally Unique Identifier. It is a 128-bit value designed to be unique across all systems, all time, and all space, without needing a central registry or coordination between the systems generating them. UUIDs are also known as GUIDs (Globally Unique Identifiers), a term popularized by Microsoft.

The UUID specification is defined in RFC 9562 (which replaced the original RFC 4122 in 2024). It defines several versions of UUIDs, each using a different method to generate unique values. The probability of generating two identical UUIDs is so astronomically low that for all practical purposes, every UUID ever generated is unique.

UUIDs solve a fundamental problem in distributed systems: how do you generate unique identifiers without a single point of coordination? In a monolithic application, you might use an auto-incrementing integer from your database. But in distributed systems with multiple servers, microservices, or offline clients, auto-incrementing IDs can collide. UUIDs provide uniqueness guarantees without any coordination.

2. The UUID Format

A UUID is typically displayed as a string of 32 hexadecimal digits grouped in a 8-4-4-4-12 pattern, separated by hyphens:

550e8400-e29b-41d4-a716-446655440000
│        │    │    │    │
│        │    │    │    └─ Node (48 bits)
│        │    │    └─ Clock sequence (16 bits)
│        │    └─ Version (4 bits) + time_hi (12 bits)
│        └─ time_mid (16 bits)
└─ time_low (32 bits)

The version number is encoded in the third group. For example, 41d4 starts with 4, indicating this is a version 4 UUID. The variant is encoded in the fourth group: values starting with 8, 9, a, or b indicate the standard RFC variant.

Despite containing hyphens in the standard representation, UUIDs are 128-bit (16-byte) values at their core. The string representation is just for human readability. When stored in databases, UUIDs can be stored as 16-byte binary values for efficiency.

3. UUID v1: Time-Based

UUID v1 generates identifiers based on the current time and the MAC address of the generating machine. The timestamp provides uniqueness over time, and the MAC address provides uniqueness across machines.

Structure:

• 60-bit timestamp (100-nanosecond intervals since October 15, 1582)
• 14-bit clock sequence (handles timestamp collisions)
• 48-bit node identifier (typically the MAC address)

Advantages:

• Naturally sortable by creation time (with some caveats about byte order)
• The timestamp can be extracted from the UUID
• Very low collision probability without requiring random number generation

Disadvantages:

• Privacy concern: The MAC address reveals the generating machine's identity, which can be a security and privacy issue
• The timestamp is not in chronological order within the UUID string, making lexicographic sorting unreliable
• Clock skew between machines can cause ordering issues

// Example UUID v1
// 6ba7b810-9dad-11d1-80b4-00c04fd430c8
//                 ^
//                 1 = version 1

4. UUID v4: Random

UUID v4 is the most widely used version. It generates identifiers using random (or pseudo-random) numbers. Of the 128 bits, 122 are randomly generated, with the remaining 6 bits used for the version (4 bits) and variant (2 bits) identifiers.

Structure:

• 122 random bits
• 4 version bits (set to 0100)
• 2 variant bits (set to 10)

Advantages:

• Simple to generate: just random numbers
• No information leakage: nothing about the generating machine, time, or sequence is revealed
• No coordination needed between generating systems
• Supported natively in virtually every programming language

Disadvantages:

• Not sortable by creation time
• Random distribution is bad for database index performance (causes random I/O patterns in B-tree indexes)
• Requires a good source of randomness (not an issue in modern systems)

// Generating UUID v4 in JavaScript
const uuid = crypto.randomUUID();
// Example: "f47ac10b-58cc-4372-a567-0e02b2c3d479"
//                       ^
//                       4 = version 4

The collision probability of UUID v4 is extraordinarily low. You would need to generate approximately 2.71 quintillion (2.71 x 10^18) UUIDs to have a 50% chance of a single collision. To put that in perspective, if you generated one billion UUIDs per second, it would take approximately 86 years to reach that threshold.

5. UUID v7: Time-Ordered Random

UUID v7 is the newest version, introduced in RFC 9562 (2024). It combines the best features of v1 and v4: time-based ordering with random uniqueness, and without the privacy concerns of exposing MAC addresses.

Structure:

• 48-bit Unix timestamp in milliseconds
• 4 version bits
• 12 random bits
• 2 variant bits
• 62 random bits

Advantages:

• Lexicographically sortable: UUIDs generated later have higher values, making them natural for use as database primary keys
• Database-friendly: The time-ordered nature produces sequential inserts in B-tree indexes, dramatically improving write performance compared to UUID v4
• No information leakage: Unlike v1, no MAC address or machine-identifying information is included
• Timestamp extractable: The creation time can be derived from the UUID
• High uniqueness: 74 random bits per millisecond provides strong collision resistance

Disadvantages:

• Newer standard: not all libraries and databases have native support yet
• Timestamp reveals approximate creation time (which may or may not be desirable)

6. Comparison: Which Version Should You Use?

Here is a quick decision guide:

• Use UUID v4 when you need maximum privacy (no timestamp), maximum compatibility, or when ordering does not matter. v4 is the safe default that works everywhere.
• Use UUID v7 when you need sortable IDs for database primary keys, want to extract creation timestamps from IDs, or care about database write performance. v7 is the modern best practice for most new applications.
• Avoid UUID v1 in new applications due to its MAC address leakage. If you need time-based UUIDs, use v7 instead.

7. Generating UUIDs in Practice

Here is how to generate UUIDs in common programming languages:

// JavaScript (v4 - native)
crypto.randomUUID();

// Python (v4)
import uuid
str(uuid.uuid4())

// Java (v4)
UUID.randomUUID().toString();

// Go (v4, using google/uuid)
uuid.New().String()

// PHP (v4)
Ramsey\Uuid\Uuid::uuid4()->toString();

For generating UUIDs quickly without writing code, or when you need bulk generation (up to 10,000 at once), tools like UUID Generator by ZeroDataUpload support v1, v4, and v7 generation entirely in your browser. All UUIDs are generated locally using cryptographic randomness, so they are suitable for production use.

8. Conclusion

UUIDs are a foundational concept in software engineering. Understanding the differences between versions helps you make informed decisions about your application's identifier strategy. UUID v4 remains the most widely used and compatible option, while UUID v7 represents the future of UUID generation with its superior database performance and sortability.

Whichever version you choose, the core guarantee remains the same: every UUID you generate will be unique, without requiring any central coordination or authority. That is a powerful property for building distributed, scalable systems.

Related Articles

Published: January 11, 2026