What Does UUID v1 Through v5 Mean? Versions Explained

If you are building a distributed system or simply setting up a database schema, you have likely encountered Universally Unique Identifiers (UUIDs). However, when you dig into the RFC 4122 specifications, you quickly realize there is more than one type available. You might find yourself asking: what does UUID v1 through v5 mean, and which one should you actually use for your project?

A UUID is a 128-bit label used for information in computer systems. To better understand how does a UUID generator actually work, it helps to know that the standard defines five specific versions. In this comprehensive guide, we break down exactly what each version does, how they differ in terms of cryptography and privacy, and when to use them in modern architectures.

1. Understanding the Basics of UUIDs

Before exploring the specific versions, you need to understand the fundamental structure of a UUID. Regardless of the algorithm used, a standard UUID contains 32 hexadecimal digits displayed in five groups separated by hyphens. The format looks like this: 8-4-4-4-12.

For example: 123e4567-e89b-12d3-a456-426614174000.

The "version" of a UUID specifies the algorithm used to generate it. You can always tell which version a UUID is by looking at the first digit of the third group. In the example above, the `1` in `12d3` indicates it is a version 1 UUID. Knowing how to generate UUIDs in your application correctly starts with picking the correct version for your requirements.

There is also a "variant" field, which indicates the layout of the UUID itself. The variant is determined by the first one to three bits of the fourth group. For the standard RFC 4122 UUIDs, this group will always start with `8`, `9`, `a`, or `b`.

If you are comparing UUID vs GUID, it is worth noting that a Microsoft GUID is essentially the exact same 128-bit structure, though historically Microsoft used different byte-ordering for certain fields. Today, the terms are used interchangeably in most programming environments.

2. UUID v1: Time and MAC Address Based

UUID version 1 uses two main ingredients: the current timestamp and the MAC address of the computer generating the UUID. The timestamp is measured in 100-nanosecond intervals since October 15, 1582, which is the date of the Gregorian calendar adoption.

The 128 bits are constructed as follows:

• 60 bits for the timestamp.
• 14 bits for the clock sequence.
• 48 bits for the node ID (the MAC address).
• 6 bits for the version and variant metadata.

The clock sequence is a crucial component. If your server generates multiple UUIDs within the exact same 100-nanosecond window, the clock sequence simply increments to prevent collisions. It also provides protection if the system clock is manually adjusted backwards.

Because it incorporates the exact hardware MAC address, a v1 UUID is guaranteed to be unique across different machines without requiring any central coordination. However, this causes serious privacy and security concerns. If you expose a v1 UUID in an API response, anyone can extract the time it was generated and the MAC address of the originating server. For modern web applications, you should evaluate why time-based UUIDs fell out of favor before implementing them.

// Extracting the timestamp from a v1 UUID in JavaScript
function getV1Timestamp(uuid_str) {
  const parts = uuid_str.split('-');
  const timeLow = parts[0];
  const timeMid = parts[1];
  const timeHi = parts[2].substring(1); // Remove version bit
  
  const hexTime = timeHi + timeMid + timeLow;
  // Convert 100-ns intervals since 1582 to a modern Unix timestamp
  return parseInt(hexTime, 16);
}

3. UUID v2: DCE Security (Rarely Used)

UUID version 2 is conceptually similar to version 1, but it replaces the low bits of the timestamp with a local identifier, such as a POSIX User ID or Group ID. This format was designed specifically for Distributed Computing Environment (DCE) security protocols.

To fit the local domain identifier into the 128-bit structure, version 2 steals 32 bits from the timestamp and 8 bits from the clock sequence. This severely restricts the generation capacity. Because 32 bits of the timestamp are replaced by a static UID, the clock only updates every 429 seconds (about 7 minutes). If a single user tries to generate more than 64 UUIDs within that 7-minute window, the generator runs out of clock sequence bits and fails.

In practice, UUID v2 is almost never used today. Most programming languages and database systems do not even provide built-in functions to generate v2 UUIDs. Its use cases are extremely narrow, and the limitations on generation speed make it completely unsuitable for high-throughput database systems.

4. UUID v3: Name-Based with MD5 Hashing

UUID version 3 takes a completely different mathematical approach. Instead of using randomness or hardware addresses, it uses a "namespace" and a "name". The generator concatenates these two inputs and hashes them using the MD5 algorithm to produce the 128-bit identifier.

The namespace itself is just another UUID. The RFC defines standard namespaces for common domains like DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8), URLs, OIDs, and X.500 Distinguished Names.

The key feature of v3 is that it is strictly deterministic. If you provide the exact same namespace and name on two different machines, you will get the exact same UUID. This is highly useful when you need to assign unique IDs to external entities consistently without storing them in a centralized database lookup table.

For example, if you want to generate an ID for the domain example.com, you can use the DNS namespace UUID and the string "example.com". Every time you run this function, the resulting UUID will be identical.

However, the MD5 hashing algorithm has known cryptographic vulnerabilities and is prone to collision attacks. While the risk of an accidental collision in a UUID context is low, MD5 is generally deprecated in modern security engineering.

5. UUID v4: Purely Random Generation

When most developers talk about UUIDs, they mean version 4. UUID v4 is generated entirely from random (or pseudo-random) numbers. Out of the 128 bits, 122 bits are purely random, leaving only 6 bits reserved for the version and variant markers.

Because it does not rely on the machine's state, hardware MAC addresses, or the current time, UUID v4 provides excellent privacy. The total number of possible v4 UUIDs is 2¹²², which equals approximately 5.3 x 10³⁶.

The probability of generating a duplicate is so infinitesimally small that you can treat them as practically unique. To put this in perspective, you would need to generate 1 billion UUIDs every second for 85 years just to reach a 50% chance of a single collision.

Under the hood, modern environments use Cryptographically Secure Pseudo-Random Number Generators (CSPRNG) to populate these 122 bits. In JavaScript, this relies on crypto.getRandomValues(), while backend servers might pull entropy from /dev/urandom. You can use our UUID v4 Generator tool to create these IDs instantly in your browser securely.

// Native UUID v4 generation in modern JavaScript environments
const newId = crypto.randomUUID();
console.log(newId); // "36b8f84d-df4e-4cb7-9bca-4b0593bcf856"

6. UUID v5: Name-Based with SHA-1 Hashing

UUID version 5 is the modern, secure successor to version 3. It operates on the exact same deterministic principle: combining a namespace UUID and a name string to generate a persistent identifier. The major difference is that version 5 uses the SHA-1 algorithm instead of MD5.

SHA-1 produces a 160-bit hash. To fit this into the 128-bit UUID structure, the algorithm truncates the hash, takes the highest 128 bits, and overwrites the relevant version and variant bits.

While SHA-1 is no longer considered secure for cryptographic digital signatures or certificate generation, it is perfectly fine for generating UUIDs where you simply need a uniform distribution of bits and deterministic output. If you need a name-based UUID today, you should always prefer version 5 over version 3.

// Example using the popular 'uuid' npm package for version 5
const { v5: uuidv5 } = require('uuid');

const MY_NAMESPACE = '1b671a64-40d5-491e-99b0-da01ff1f3341';
const name = 'hello_world';

const deterministicId = uuidv5(name, MY_NAMESPACE);
console.log(deterministicId); 
// Always produces: '630eb68f-e0fa-5ce2-f9b4-523c6a4613eb'

7. What Does UUID v1 Through v5 Mean for Your Architecture?

Now that you understand the UUID version differences, you need to pick the right one for your application stack. Choosing the incorrect version can lead to performance bottlenecks, security flaws, or distributed data conflicts.

When to use Version 4:
If you just need a random unique ID for a database primary key, an API session token, or an uploaded file name, version 4 is the industry standard. It requires no configuration, leaks zero metadata, and prevents Insecure Direct Object Reference (IDOR) attacks because the IDs are completely unpredictable.

When to use Version 5:
If you need to generate the same ID repeatedly from a given string without saving it in a lookup table, use version 5. For example, if you are importing massive amounts of user data from a third-party API and want to prevent duplicate records, you can hash the user's email address into a v5 UUID. When the job runs again, the identical email will generate the identical UUID, naturally causing a database conflict that you can handle via an "upsert" operation.

When to avoid Versions 1 and 2:
Unless you are working with legacy systems that strictly require them, avoid time-based UUIDs. The privacy implications of leaking MAC addresses are severe. Furthermore, if you are generating IDs concurrently across multi-threaded environments, you risk clock sequence exhaustion.

Database Indexing Considerations:
Because v4 UUIDs are completely random, inserting them into a standard B-Tree index (like those used in PostgreSQL or MySQL) can cause severe index fragmentation. Every new insert goes into a random location in the index, leading to heavy page splits and disk I/O. If you are experiencing performance issues with massive tables, you may want to look into sequential variations like UUID v7, which combine a Unix timestamp with random data to keep inserts sequential while maintaining privacy.

8. Frequently Asked Questions

9. Conclusion

Understanding what does UUID v1 through v5 mean is essential for designing robust, secure database schemas and distributed systems. While versions 1 and 2 rely on hardware addresses and time, exposing potential privacy risks, version 4 relies purely on high-quality randomness. For scenarios where you need deterministic identifiers based on external data sources, version 5 provides a reliable SHA-1 hashing approach.

For modern web development, software engineering, and API design, you will likely default to UUID v4 for generating primary keys and session tokens, leveraging its simplicity and strong privacy guarantees. By understanding the mechanics behind each version, you can prevent database performance bottlenecks and secure your infrastructure against predictive attacks.