UUID Generator

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122. UUIDs are designed to be globally unique without requiring a central registration authority — any system can generate one independently with near-zero risk of duplication.

UUIDs are ubiquitous in software engineering. They serve as primary keys in databases, correlation IDs in distributed systems, session tokens in web applications, and identifiers in APIs. Their decentralized nature makes them ideal for systems where coordination between ID generators is impractical or impossible.

The canonical text representation of a UUID is 36 characters: 32 hexadecimal digits displayed in five groups separated by hyphens, following the pattern 8-4-4-4-12.

UUID Versions

Not all UUIDs are created equal. The version number (encoded in the 13th character) determines how the UUID is generated. Each version makes different trade-offs between uniqueness guarantees, sortability, and privacy.

Version 1 — Time + MAC Address

UUID v1 combines a 60-bit timestamp (100-nanosecond intervals since October 15, 1582) with the generating machine’s 48-bit MAC address and a 14-bit clock sequence. This guarantees uniqueness across machines and time, but exposes the creator’s hardware identity.

Version 3 — MD5 Namespace Hash

UUID v3 generates a deterministic UUID by hashing a namespace UUID and a name using MD5. The same namespace + name always produces the same UUID. Useful for generating reproducible IDs from known inputs, but MD5 is considered cryptographically weak.

Version 4 — Random

UUID v4 fills 122 of the 128 bits with cryptographically random data (6 bits are reserved for version and variant). This is the most widely used version due to its simplicity and strong uniqueness guarantees. No coordination, no timestamps, no MAC addresses — just randomness.

Version 5 — SHA-1 Namespace Hash

UUID v5 works like v3 but uses SHA-1 instead of MD5. Preferred over v3 for new applications due to SHA-1’s stronger collision resistance (though SHA-1 is also deprecated for cryptographic use, it remains adequate for namespace hashing).

Version 7 — Time-Ordered Random (RFC 9562)

UUID v7 is the newest addition, defined in RFC 9562 (2024). It embeds a Unix timestamp in milliseconds in the most significant 48 bits, followed by random data. The result is a UUID that is both unique and chronologically sortable — ideal for database primary keys where B-tree index performance matters.

UUID Structure

Every UUID follows the same 128-bit layout, but the interpretation of certain bits depends on the version:

The version nibble is the first hex digit of the third group. A 4 means UUID v4 (random), a 7 means UUID v7 (time-ordered), and so on.

The variant bits occupy the most significant bits of the fourth group. For RFC 4122 UUIDs, the leading bits are 10 in binary, which means the first hex digit of that group is always 8, 9, a, or b.

Version Comparison

Version	Source	Sortable	Privacy	Best For
v1	Timestamp + MAC	Partially	Low (MAC exposed)	Legacy systems
v4	Random	No	High	General purpose, APIs
v5	SHA-1(namespace + name)	No	High	Deterministic IDs from known inputs
v7	Timestamp + Random	Yes	High	Database PKs, event logs

When to Use Which Version

UUID v4 is the safe default. It works everywhere, requires no coordination, and reveals nothing about the generating system. Use it for API identifiers, session tokens, correlation IDs, and anywhere uniqueness is the primary concern.

UUID v7 is the best choice for database primary keys. Traditional random UUIDs (v4) cause B-tree index fragmentation because new values are scattered across the index. UUID v7 values are monotonically increasing (because the timestamp comes first), so new rows are always appended to the end of the index — just like auto-incrementing integers, but without a central sequence.

UUID v5 is ideal when you need deterministic, reproducible IDs. Given the same namespace and name, v5 always produces the same UUID. This is useful for generating stable IDs from URLs, DNS names, or other known inputs without storing a mapping table.

Common Use Cases

• Database primary keys: UUIDs eliminate the need for centralized sequence generators, enabling distributed systems to create records independently without conflicts
• API resource identifiers: UUIDs in URLs (/users/550e8400-e29b-41d4-a716-446655440000) are non-sequential, preventing enumeration attacks
• Distributed tracing: Correlation IDs (UUIDs) track requests across microservices, appearing in logs from every service that handles the request
• File and asset naming: UUIDs prevent filename collisions when multiple users upload files simultaneously
• Idempotency keys: APIs use client-generated UUIDs to ensure a request is processed only once, even if retried