The Complete UUID Guide: Versions, Use Cases, and Best Practices

The Need for Universally Unique Identifiers

In the early days of computing, unique identification was simple. A single database assigned auto-incrementing integers: 1, 2, 3, 4, and so on. This approach worked perfectly when one machine generated all the IDs.

Modern software architecture looks nothing like that. Today’s applications run across distributed databases, microservices, edge computing nodes, offline-first mobile apps, and serverless functions. ID generation happens simultaneously across dozens—sometimes hundreds—of independent processes that cannot coordinate in real time.

The consequences of ID collisions in these environments are severe. Duplicate primary keys cause data corruption during database merges. Predictable sequential IDs enable enumeration attacks. Shared ID generation services create single points of failure and performance bottlenecks.

UUIDs (Universally Unique Identifiers) solve these problems. A UUID is a 128-bit identifier designed to be unique across all devices in all networks, without any central coordination. The probability of collision is so small that it is considered negligible for all practical purposes.

This guide covers every UUID version defined in RFC 9562, analyzes their entropy characteristics, compares UUIDs with alternative ID schemes, and provides practical implementation guidance for production systems.

---

What is a UUID?

A UUID is a 128-bit value that can be generated locally on any device, with a collision probability that is statistically zero. UUIDs are represented as 36-character hexadecimal strings divided into five groups by hyphens:

550e8400-e29b-41d4-a716-446655440000

The five groups correspond to:

Group	Length	Field Name	Description
1	8 hex chars	time-low	Lowest 32 bits of the timestamp
2	4 hex chars	time-mid	Middle 16 bits of the timestamp
3	4 hex chars	time-high-and-version	Highest 12 bits of timestamp + version
4	4 hex chars	clock-seq-and-reserved	Clock sequence + variant indicator
5	12 hex chars	node	MAC address or random identifier

The 128-bit value provides $2^{128} \approx 3.4 \times 10^{38}$ possible combinations. You can generate UUIDs instantly using our client-side UUID Generator.

---

UUID Version Comparison

The UUID specification defines eight versions, each using a different generation mechanism:

Version	Generation Method	Entropy Bits	Sortable	Timestamp Leaked	Use Case
V1	Timestamp + MAC	60	Time-ordered	Yes (MAC + time)	Legacy distributed systems
V2	DCE Security	60	Time-ordered	Yes	DCE/POSIX systems
V3	MD5 hash (deterministic)	122	No	No	Deterministic name-based
V4	Random	122	No	No	General-purpose
V5	SHA-1 hash (deterministic)	122	No	No	Deterministic (stronger)
V6	Reordered V1	60	Lexicographic	Yes (MAC + time)	Ordered distributed DBs
V7	Timestamp + Random	74	Lexicographic	Partial (ms only)	Modern ordered databases
V8	Custom	128	Varies	Varies	Application-specific

---

UUID Version 1: Time-Based

UUID v1 generates identifiers using the device’s MAC address and a 100-nanosecond resolution timestamp.

Structure

time_low.time_mid.time_hi_and_version.clock_seq_and_reserved.node

• Timestamp (60 bits): Counts 100-nanosecond intervals since October 15, 1582 (the Gregorian calendar reform date). This provides a range of approximately 3,400 years.
• Clock Sequence (14 bits): Prevents duplicates when the system clock is reset or when multiple UUIDs are generated in the same tick.
• Node (48 bits): The device’s MAC address, or a random value if no MAC is available.

Strengths

• Time-ordered (enables chronological sorting)
• Globally unique without coordination
• Timestamp allows creation time inference

Weaknesses

• Leaks the device’s MAC address (privacy concern)
• Leaks the exact creation time (privacy concern)
• MAC address can be spoofed, reducing uniqueness guarantees
• Clock rollback can produce duplicates (mitigated by clock sequence)

When to Use V1

Use V1 only in legacy systems that require time-based ordering and do not have privacy requirements. For new applications, prefer V6 or V7.

---

UUID Version 3 and 5: Name-Based (Deterministic)

UUID v3 and v5 generate deterministic identifiers by hashing a namespace identifier and a name string. The same input always produces the same UUID.

Structure

hash(namespace + name)

• Namespace: A UUID that identifies the naming context (e.g., DNS, URL, OID, X500)
• Name: An arbitrary string identifier within the namespace

V3 vs. V5

Property	UUID V3	UUID V5
Hash Algorithm	MD5	SHA-1
Security	Weak (MD5 collisions exist)	Strong (SHA-1 collision-resistant)
Speed	Faster	Slightly slower
Recommended	No (for new applications)	Yes

Example

UUID V5 (DNS namespace, "example.com")
= 9073926b-929f-4f2b-a2c4-8e5bb3f66e61

Strengths

• Deterministic (same input always produces the same UUID)
• No central authority needed
• Namespace separation prevents cross-domain collisions
• SHA-1 in V5 provides strong collision resistance

Weaknesses

• Not random (output can be predicted from input)
• V3 uses MD5, which has known collision vulnerabilities
• Requires namespace management

When to Use Name-Based UUIDs

• Generating consistent IDs for DNS entries, URLs, or other named resources
• Creating deterministic database keys from human-readable identifiers
• Deriving IDs that must be reproducible across multiple systems

---

UUID Version 4: Random

UUID v4 is the most widely used version in modern software. It generates identifiers using cryptographically secure random values.

Structure

random_time_low.time_mid.version_and_random_high.clock_seq_variant.random_node

• 122 bits of random data (from a cryptographically secure random number generator)
• 6 bits of metadata (4 bits for version “0100” = 4, 2 bits for variant “10”)

Entropy Analysis

With 122 random bits, UUID v4 provides $2^{122} \approx 5.3 \times 10^{36}$ possible values. The entropy is equivalent to a 122-bit secret key—computationally infeasible to guess or enumerate.

Collision Probability

Using the birthday paradox approximation, the number of UUIDs needed for a 50% chance of a single collision is approximately:

$$N_{50%} \approx \sqrt{2 \times 2^{122}} \approx 2.7 \times 10^{18}$$

UUIDs Generated	Collision Probability
1 million	~0.0000000000000000001%
1 billion	~0.00000000000000001%
1 trillion	~0.000000000000001%
1 quadrillion	~0.0000000000001%
$2.7 \times 10^{18}$	~50%

To put this in perspective: generating 1 billion UUIDs per second for 85 years yields only about a 50% chance of encountering a single duplicate. For all practical applications, UUID v4 collisions are impossible.

Strengths

• Maximum randomness (122 bits)
• No information leakage (no timestamp, no MAC)
• Simple generation (no state management)
• Universally supported across all programming languages

Weaknesses

• Not sortable (random values prevent chronological ordering)
• Can cause database index fragmentation (B-Tree splits)
• No built-in timestamp information

When to Use V4

• General-purpose unique identifiers
• Session tokens and API keys
• Database primary keys where ordering is not important
• Any scenario requiring unpredictable identifiers

Generate cryptographically secure UUIDs using our UUID Generator.

---

UUID Version 6: Reordered Time-Based

UUID v6 is a reordering of v1 that places the timestamp in the most significant bits, making UUIDs sortable in lexicographic (string) order.

Structure

time_high.time_mid.time_low_and_version.clock_seq_and_reserved.node

The timestamp bits are rearranged so that UUIDs generated later are always greater than UUIDs generated earlier when compared as strings.

Strengths

• Lexicographically sortable (improves database B-Tree performance)
• Compatible with v1 timestamp semantics
• Useful for systems migrating from v1

Weaknesses

• Still leaks MAC address and full timestamp (privacy concern)
• Requires MAC address or random node identifier
• 60 bits of entropy (less than v4’s 122 bits)

When to Use V6

Use V6 when you need time-ordered UUIDs in a distributed system and privacy is not a concern. For new applications, UUID v7 is generally preferred.

---

UUID Version 7: Time-Ordered Random

UUID v7 is the newest recommended standard, combining a Unix millisecond timestamp with random bits to create time-ordered, collision-resistant identifiers.

Structure

unix_ts_ms (48 bits) | rand_a (10 bits) | version (4 bits) | rand_b (62 bits) | variant (2 bits)

• 48-bit Unix timestamp in milliseconds: Provides time ordering and allows creation time inference
• 74 random bits: Provides strong collision resistance within the same millisecond
• 6 bits of metadata: Version (0111 = 7) and variant (10)

Entropy Analysis

UUID v7 has 74 random bits, providing $2^{74} \approx 1.9 \times 10^{22}$ possible values per millisecond. The collision risk only exists for UUIDs generated within the same millisecond on the same machine.

To reach a 50% collision probability within a single millisecond, you would need to generate approximately $1.9 \times 10^{11}$ UUIDs in that millisecond—far beyond the capability of any current system.

Strengths

• Lexicographically sortable (timestamp in most significant bits)
• Time-ordered (improves database insertion performance by 30-50%)
• High entropy (74 random bits)
• Unix timestamp enables natural time ordering
• No MAC address leakage

Weaknesses

• Slightly less random entropy than v4 (74 vs. 122 bits)
• Timestamp reveals approximate creation time
• Newer standard (wider adoption needed)

When to Use V7

• High-performance databases where insertion order matters
• Distributed systems requiring time-ordered records
• Any application where you need both uniqueness and chronological sorting -替代方案 to UUID v4 when database performance is critical

---

UUID Version 8: Custom

UUID v8 is a reserved version for application-specific UUIDs. The 128 bits can be used for any custom purpose while maintaining UUID format compatibility.

Structure

custom_data (122 bits) | version (4 bits) | variant (2 bits)

Use Cases

• Encoding additional metadata into the UUID format
• Custom ID schemes that must coexist with standard UUIDs
• Proprietary identification systems

---

UUID Storage Efficiency

The choice of UUID format impacts database storage and performance:

ID Type	Storage Size	String Size	Index Size (InnoDB)	1M Records
INT (auto-increment)	4 bytes	10 chars	~4 bytes	~8 MB
BIGINT	8 bytes	19 chars	~8 bytes	~16 MB
UUID (binary)	16 bytes	36 chars	~16 bytes	~32 MB
UUID (string)	36 bytes	36 chars	~36 bytes	~72 MB
ULID (binary)	16 bytes	26 chars	~16 bytes	~32 MB

Storage Best Practices

1. Store as binary: Always store UUIDs as BINARY(16) or native UUID types, not strings.
2. Use database-native types: PostgreSQL, MySQL 8.0+, and most modern databases have native UUID column types.
3. Consider sequential alternatives: For high-volume insert-heavy workloads, consider ULID, NanoID, or UUID v7.

---

UUID vs. Alternative ID Strategies

Property	UUID V4	UUID V7	ULID	NanoID	CUID2	Sequential INT
Size	128 bits	128 bits	128 bits	Configurable	Configurable	32-64 bits
Sortable	No	Yes (lexicographic)	Yes (lexicographic)	Optional	Partial	Yes
Time-Ordered	No	Yes	Yes	No	No	Yes
Collision Resistant	Yes	Yes	Yes	Yes	Yes	Single DB only
URL-Safe	Yes	Yes	Yes	Yes	Yes	Yes
Human-Readable	No	No	Partial	Yes	Partial	Yes
Offline Generation	Yes	Yes	Yes	Yes	Yes	No
Privacy	High	High	High	High	High	Low

ULID: A Close Alternative

ULID (Universally Unique Lexicographically Sortable Identifier) uses Crockford’s Base32 encoding to produce 26-character strings that are URL-friendly, case-insensitive, and sortable. ULID and UUID v7 serve similar purposes—time-ordered, collision-resistant identifiers—but ULID is more compact and easier to read.

Property	UUID V7	ULID
String Length	36 characters	26 characters
Alphabet	Hexadecimal (0-9, a-f)	Crockford’s Base32 (0-9, A-Z)
Case Sensitivity	Yes	No (case-insensitive)
URL-Safe	Yes (with hyphens)	Yes (no special characters)
Entropy	74 random bits	80 random bits
Sortability	Lexicographic	Lexicographic
Time Resolution	Milliseconds	Milliseconds

For detailed ULID analysis, see our guide on What is a UUID and When Should You Use One.

---

Practical Implementation

Generating UUIDs in Code

JavaScript (Browser/Node.js):

// Native browser support
const uuid = crypto.randomUUID();
console.log(uuid); // "550e8400-e29b-41d4-a716-446655440000"

// Or use our browser-based tool
// https://generatepass.me/uuid-generator

Python:

import uuid

# Version 4 (random)
print(uuid.uuid4())  # "550e8400-e29b-41d4-a716-446655440000"

# Version 5 (name-based, SHA-1)
print(uuid.uuid5(uuid.NAMESPACE_DNS, "example.com"))

Go:

import "github.com/google/uuid"

id := uuid.New()
fmt.Println(id.String()) // "550e8400-e29b-41d4-a716-446655440000"

SQL (PostgreSQL):

-- Generate UUID v4
SELECT gen_random_uuid();

-- Store as native UUID type
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(255)
);

Online Generation

Generate UUIDs instantly using our browser-based UUID Generator. All generation happens client-side—no data is ever sent to any server. You can also generate Secret Tokens and Passwords for related security needs.

---

Frequently Asked Questions

Which UUID version should I use for new projects?

For most new projects, use UUID v7 (time-ordered random) or UUID v4 (pure random). UUID v7 is ideal when database insertion performance matters. UUID v4 is ideal when maximum randomness is the priority. Both provide strong collision resistance and are widely supported.

Can UUIDs be guessed by attackers?

UUID v4 and v7 have sufficient entropy (122 and 74 random bits respectively) to make brute-force guessing computationally infeasible. UUID v1 and v6 leak the timestamp and MAC address, which can theoretically be used to predict future UUIDs. For security-sensitive applications, always use v4, v5, or v7.

How many UUIDs can I generate before a collision?

For UUID v4, you would need to generate approximately $2.7 \times 10^{18}$ (2.7 quintillion) UUIDs to reach a 50% collision probability. At 1 billion UUIDs per second, this would take approximately 85 years. For all practical purposes, collisions are impossible.

Should I store UUIDs as strings or binary?

Store UUIDs as binary (16 bytes) for better performance and storage efficiency. Most databases support native UUID types that handle binary storage automatically. Only use string format for display in API responses or user interfaces. You can serialize binary data using our [Base64 Converter](/base64-converter).

What is the difference between UUID and NanoID?

NanoID is a URL-friendly unique string ID generator that produces shorter, more readable IDs (default 21 characters vs. UUID's 36). NanoID is popular for URL shorteners, invite codes, and user-facing identifiers where readability matters. UUIDs provide stronger guarantees and are better for database primary keys.

Do UUIDs slow down my database?

UUID v4 (random) can cause B-Tree index fragmentation, reducing insert performance by 30-50% compared to sequential integers. UUID v7 (time-ordered) largely eliminates this issue by producing sequentially ordered values. If insert performance is critical, use UUID v7 or consider sequential alternatives like ULID.

---

About the Author

The GeneratePass Editorial Team builds privacy-first security tools that run entirely in your browser. Every tool on GeneratePass processes data locally — nothing is ever sent to a server. Visit generatepass.me to try our free Password Generator, Entropy Calculator, and Breach Checker.