What Is a UUID? Format, Versions, and How They Work

A UUID (Universally Unique Identifier) is a 128-bit identifier designed to be unique across space and time without requiring a central authority to assign them. The format is standardized in RFC 4122.

The UUID format

A UUID looks like this:

550e8400-e29b-41d4-a716-446655440000

It has 32 hexadecimal digits displayed in 5 groups separated by hyphens (8-4-4-4-12):

550e8400 - e29b - 41d4 - a716 - 446655440000
xxxxxxxx   xxxx   xxxx   xxxx   xxxxxxxxxxxx

Total: 32 hex characters = 128 bits = 16 bytes

UUID structure (RFC 4122)

The bits are organized into fields with specific meanings:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
              │    │
              │    └── Variant bits (N): identifies the RFC/variant
              └─────── Version bits (M): identifies the version (1-8)

• M (version nibble): 1 = time-based, 4 = random, 7 = time-ordered random
• N (variant bits): must be 8, 9, a, or b for RFC 4122 UUIDs

UUID versions

UUID v1 (Time-based)

Encodes the current timestamp (100-nanosecond intervals since October 15, 1582) and the MAC address of the generating machine.

Pros: sortable by generation time, no collision risk
Cons: leaks MAC address, not sortable in standard UUID field order

Not recommended for new applications — v7 is the better time-ordered alternative.

UUID v3 (Name-based, MD5)

A UUID generated by hashing a namespace UUID and a name using MD5. Same name + namespace always produces the same UUID.

import uuid
namespace = uuid.NAMESPACE_URL
name = "https://example.com"
result = uuid.uuid3(namespace, name)
# Always the same for the same inputs

UUID v4 (Random)

Generated from 122 bits of cryptographically random data. The version and variant bits are fixed; the rest is random.

Pros: simple, no information leakage, widely supported
Cons: not sortable (random order causes B-tree index fragmentation)

v4 is the most common UUID type. Use it when you need unique IDs and sortability isn’t a concern.

UUID v5 (Name-based, SHA-1)

Like v3 but uses SHA-1 instead of MD5. Preferred over v3.

UUID v7 (Time-ordered random) — RFC 9562, 2024

The newest and now recommended UUID version. Uses a Unix timestamp prefix followed by random bits, giving a monotonically increasing UUID that sorts by creation time.

017f22e2-79b0-7cc3-98c4-dc0c0c07398f
├───────────────┤
Unix timestamp ms  └── random bits

Pros: lexicographically sortable, ideal for database PKs, good randomness
Cons: slightly newer, support still spreading

Why UUIDs are practically unique

v4 UUIDs use 122 random bits (the 6 non-random bits are version/variant). The total number of possible v4 UUIDs is:

2^122 ≈ 5.3 × 10^36

The probability of a collision when generating 1 billion UUIDs per second for 100 years is approximately 0.00000000006% — effectively zero for any real application.

UUID vs. sequential IDs

Property	UUID (v4)	UUID (v7)	Auto-increment
Globally unique	Yes	Yes	No
No central authority	Yes	Yes	No (needs DB)
Predictable	No	No	Yes (enumerable)
Sortable by creation	No	Yes	Yes
DB index performance	Poor (fragmentation)	Good	Good
Storage	16 bytes	16 bytes	4-8 bytes
URL-safe	Yes	Yes	Yes

Use auto-increment for simple single-database applications where enumeration isn’t a concern. Use UUIDs for distributed systems, public-facing IDs, or when you need to generate IDs client-side.

The nil and max UUIDs

Nil UUID — all zeros:

00000000-0000-0000-0000-000000000000

Used as a sentinel value (“no UUID” or “unset”).

Max UUID — all ones (all ‘f’):

ffffffff-ffff-ffff-ffff-ffffffffffff

Defined in RFC 9562 as a special value.

Generate UUIDs at uuidgen.io.