UUID Guide: Understanding v1, v4, and v5 Versions

Updated March 2026 · 7 min read

Universally Unique Identifiers (UUIDs) are 128-bit values used to identify resources without a central authority. They are used everywhere: database primary keys, API request IDs, session tokens, distributed systems, and message queues. Understanding UUID versions helps you pick the right one for your use case.

UUID Format

A UUID is displayed as 32 hexadecimal digits in five groups separated by hyphens, following the pattern 8-4-4-4-12:

550e8400-e29b-41d4-a716-446655440000
|        |    |    |    |
|        |    |    |    +-- Node (48 bits)
|        |    |    +------- Clock seq (16 bits)
|        |    +------------ Version (4 bits) + Time high
|        +----------------- Time mid (16 bits)
+-------------------------- Time low (32 bits)

The version number is encoded in the 13th hex digit (the first digit of the third group). For example, 550e8400-e29b-41d4-a716-446655440000 is a version 4 UUID.

UUID Versions Compared

Version	Based On	Deterministic?	Best For
v1	Timestamp + MAC address	No	Time-ordered IDs, distributed systems
v3	Namespace + Name (MD5)	Yes	Reproducible IDs from known inputs
v4	Random	No	General purpose, most common choice
v5	Namespace + Name (SHA-1)	Yes	Reproducible IDs (preferred over v3)

UUID v1: Timestamp-Based

Version 1 UUIDs combine the current timestamp (100-nanosecond intervals since October 15, 1582) with the MAC address of the generating machine.

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

Pros: Naturally sorted by creation time, useful for time-series data and distributed logging.

Cons: Leaks the MAC address and creation timestamp, which can be a privacy concern. Two IDs generated at the same time on the same machine may collide without a clock sequence.

When to use: Time-ordered database indexes, event sourcing, audit logs where temporal ordering matters.

UUID v4: Random

Version 4 is the most widely used UUID version. It generates 122 random bits (the remaining 6 bits encode the version and variant).

// Example v4 UUIDs:
f47ac10b-58cc-4372-a567-0e02b2c3d479
9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d
                ^--- version digit = 4

Collision probability: With 122 bits of randomness, you would need to generate approximately 2.7 quintillion UUIDs to have a 50% chance of a single collision. In practice, collisions are virtually impossible.

When to use: Primary keys, API request IDs, session identifiers, anywhere you need a unique ID without coordination.

UUID v5: Name-Based (SHA-1)

Version 5 generates a deterministic UUID from a namespace and a name using SHA-1 hashing. The same namespace + name always produces the same UUID.

// Namespace: DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8)
// Name: "devtoolkit.ink"
// Result: always the same UUID

// Standard namespaces:
DNS:  6ba7b810-9dad-11d1-80b4-00c04fd430c8
URL:  6ba7b811-9dad-11d1-80b4-00c04fd430c8
OID:  6ba7b812-9dad-11d1-80b4-00c04fd430c8
X500: 6ba7b814-9dad-11d1-80b4-00c04fd430c8

When to use: When you need the same identifier for the same input across different systems without coordination. Useful for content-addressable storage, URL shorteners, and deduplication.

UUID v7: The New Standard (RFC 9562)

UUID v7 was introduced in RFC 9562 (2024) and is gaining rapid adoption. It combines a Unix timestamp in milliseconds with random bits, giving you time-ordered UUIDs without leaking MAC addresses:

// UUID v7 structure:
018f26a0-c7b0-7xxx-xxxx-xxxxxxxxxxxx
|              |^--- version 7
+--------------+--- millisecond timestamp

UUID v7 is becoming the recommended choice for database primary keys because it provides natural ordering (great for B-tree indexes) without the privacy concerns of v1.

Generating UUIDs in Code

# Python
import uuid
uuid.uuid4()              # Random (v4)
uuid.uuid1()              # Timestamp (v1)
uuid.uuid5(uuid.NAMESPACE_DNS, "devtoolkit.ink")  # Name-based (v5)

// JavaScript (Web Crypto API)
crypto.randomUUID()       // v4 (modern browsers)

// Node.js
const { randomUUID } = require('crypto');
randomUUID();             // v4

// Go
import "github.com/google/uuid"
uuid.New()                // v4

// Bash
uuidgen                   # Usually v4 (platform-dependent)

UUID vs. Other ID Formats

Format	Length	Sortable?	Notes
UUID v4	36 chars	No	Standard, widely supported
UUID v7	36 chars	Yes	Time-ordered, new standard
ULID	26 chars	Yes	Compact, Crockford Base32
nanoid	21 chars	No	URL-safe, compact
CUID2	24 chars	Yes	Collision-resistant
Auto-increment	Varies	Yes	Leaks count, single-DB only

Best Practices

Default to UUID v4 for most use cases. It is simple, universally supported, and collision-free in practice.
Use UUID v7 for database primary keys where insert performance matters (B-tree friendly ordering).
Use UUID v5 when you need deterministic, reproducible IDs from known inputs.
Store UUIDs as binary (16 bytes) in databases when possible. The string representation (36 chars) wastes space and is slower to index.
Never use UUIDs as secrets. UUID v1 is predictable, and v4 is not guaranteed to be cryptographically random in all implementations. Use a password generator for secrets and hash functions for integrity checks.

FAQ

Is UUID the same as GUID?

Yes. GUID (Globally Unique Identifier) is Microsoft's term for UUID. They follow the same format and standards.

Can UUID v4 collisions actually happen?

Theoretically yes, but the probability is astronomically low. Generating 1 billion UUIDs per second for 86 years gives roughly a 50% chance of one collision. For practical purposes, collisions do not happen.

Should I use UUIDs as primary keys in my database?

UUID v4 works but can fragment B-tree indexes due to random ordering. UUID v7 or ULID are better choices for primary keys because they are time-ordered. Alternatively, use auto-increment IDs internally and expose UUIDs externally.

Try UUID Generator Now →

DevToolKit — 42+ Free Online Developer Tools