UUID Versions Explained

What Is a UUID?

A Universally Unique Identifier (UUID) is a 128-bit label used to identify information in computer systems without requiring a central authority. UUIDs are standardized by RFC 9562 (which supersedes RFC 4122) and are formatted as 32 hexadecimal digits displayed in five groups separated by hyphens:

UUID Versions at a Glance

Version 1 — Timestamp + Node

UUID v1 combines a 60-bit timestamp (100-nanosecond intervals since October 15, 1582) with a 48-bit node identifier (typically the MAC address of the generating machine).

Pros:

• Guaranteed unique without coordination (if MAC addresses are unique)
• Contains embedded timestamp for auditing

Cons:

• Leaks MAC address (privacy concern)
• Not lexicographically sortable by time
• Poor database index performance due to non-sequential nature

When to use: Legacy systems that require v1 compatibility. For new projects, prefer v7.

Version 3 — MD5 Namespace Hash

UUID v3 generates a deterministic UUID by hashing a namespace UUID and a name using MD5. Given the same namespace and name, the output is always identical.

Standard Namespaces:

• DNS: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
• URL: 6ba7b811-9dad-11d1-80b4-00c04fd430c8
• OID: 6ba7b812-9dad-11d1-80b4-00c04fd430c8
• X.500: 6ba7b814-9dad-11d1-80b4-00c04fd430c8

When to use: When you need the same input to always produce the same UUID. Prefer v5 for new implementations since SHA-1 is stronger than MD5.

Version 4 — Random

UUID v4 is generated entirely from cryptographically secure random data. Of the 128 bits, 122 are random (6 bits are used for version and variant markers).

With 2^122 possible values (~5.3 × 10^36), the probability of collision is astronomically low. You would need to generate approximately 2.71 × 10^18 UUIDs to have a 50% chance of a single collision.

When to use: The default choice for most applications. Simple, fast, and requires no coordination between systems.

Version 5 — SHA-1 Namespace Hash

UUID v5 is identical in concept to v3 but uses SHA-1 instead of MD5 for the hash function. It produces deterministic UUIDs from a namespace + name pair — meaning the same namespace and name will always produce the exact same UUID, on any machine, at any time. This is the opposite of v4’s randomness: there is no randomness involved, only a one-way hash of the input. This makes v5 ideal for generating stable, reproducible identifiers from known data (e.g. always mapping "[email protected]" to the same UUID).

When to use: Whenever you need the same input to always yield the same UUID. Preferred over v3 for all new implementations since SHA-1 is a stronger hash than MD5.

Version 6 — Reordered Timestamp

UUID v6 contains the same timestamp data as v1 but reorders the bits so that UUIDs sort lexicographically by creation time. This addresses v1’s biggest weakness: poor database indexing.

When to use: When you need timestamp-based UUIDs that sort correctly. However, v7 is simpler and generally preferred for new projects.

Version 7 — Unix Timestamp

UUID v7 is the modern successor for time-based UUIDs. It embeds a standard Unix timestamp in milliseconds in the first 48 bits, followed by 74 bits of randomness.

Pros:

• Lexicographically sortable by creation time
• Uses familiar Unix timestamps (easy to extract and debug)
• Excellent database index performance (monotonically increasing)
• No privacy concerns (no MAC address)

Cons:

• Slightly less random bits than v4 (74 vs 122)

When to use: The recommended choice for database primary keys, distributed systems, and any application that benefits from time-ordered IDs. This is the version you should use for most new projects.

Version 8 — Custom / Experimental

UUID v8 provides a framework for custom UUID implementations. The only requirement is that the version bits (4 bits) and variant bits (2 bits) are set correctly. The remaining 122 bits are available for custom use.

When to use: When you have specific requirements not met by other versions. For example, embedding additional metadata like region codes, shard IDs, or custom timestamps.

GUID — Globally Unique Identifier

GUID (Globally Unique Identifier) is Microsoft’s term for UUID. Functionally, a GUID is identical to a UUID v4 — 122 random bits with version and variant markers. The only traditional difference is formatting:

In modern practice, the terms are interchangeable. Our generator produces uppercase UUIDs for the GUID format.

When to use: When working in the Microsoft ecosystem (.NET, SQL Server, Azure) or when documentation specifically calls for GUIDs.

Which Version Should I Use?

For most developers, the decision tree is simple:

1. Need time-sorted IDs? → Use v7
2. Need deterministic IDs from a name? → Use v5
3. Need maximum compatibility? → Use v4
4. Working with Microsoft/.NET? → Use GUID (v4 uppercase)
5. Need custom embedded data? → Use v8
6. Maintaining legacy systems? → Keep using v1 or v3

For new projects in 2026, UUID v7 is the recommended default for database primary keys and distributed systems, while UUID v4 remains the safest general-purpose choice.

Security Considerations

• UUIDs are not secrets. They should not be used as authentication tokens or access keys.
• UUID v1/v6 embed timestamps and potentially MAC addresses — consider privacy implications.
• Always use a cryptographically secure random number generator (CSPRNG) for v4/v7/v8 generation. Our tools use the Web Crypto API’s crypto.getRandomValues().
• While collision probability is extremely low for v4, don’t rely on uniqueness as a security guarantee in adversarial contexts.