UUID versions
The UUID specification defines several versions, each with a different generation strategy:
| Version | Strategy | Use case |
|---|---|---|
| v1 | Time + MAC address | Sortable, but leaks machine identity |
| v3 | MD5 hash of namespace + name | Deterministic, reproducible |
| v4 | Fully random | General purpose — most widely used |
| v5 | SHA-1 hash of namespace + name | Deterministic, stronger than v3 |
| v7 | Timestamp prefix + random bits | Sortable + unique — best for DB primary keys |
Version 4 is the most common choice for general-purpose IDs. Version 7 (RFC 9562, 2024) is increasingly preferred for database primary keys because its timestamp prefix maintains monotonic ordering, which reduces index fragmentation in B-tree databases.
When to use a UUID
UUIDs are a good default in these scenarios:
- Distributed databases — multiple independent sources generate records that must merge without conflicts.
- Public-facing IDs — sequential integers like
/users/1,/users/2allow enumeration. A UUID endpoint like/users/550e8400-...reveals nothing about total record counts. - Idempotency keys — for API requests where you want to safely retry without creating duplicates.
- Correlation IDs — for distributed tracing across microservices.
- Uploaded asset names — collision-free naming without a database lookup.
Trade-offs vs. other ID strategies
No ID strategy is universally best. Here is how the common options compare:
| Strategy | Size | Ordered | Collision-safe | Central coord. required |
|---|---|---|---|---|
| Auto-increment integer | 4–8 bytes | Yes | Within one DB | Yes |
| UUID v4 | 16 bytes | No | Yes | No |
| UUID v7 | 16 bytes | Yes | Yes | No |
| ULID | 16 bytes | Yes | Yes | No |
| NanoID (21 chars) | ~15 bytes | No | Practically yes | No |
The main downsides of UUID v4 are size and randomness. At 36 characters (16 bytes binary), they are larger than a 4-byte integer and cause index fragmentation in B-tree databases because new values insert at unpredictable positions. UUID v7 and ULID solve the ordering problem while keeping collision resistance.
UUID v4 generation and uniqueness
UUID v4 generates 122 bits of randomness (6 bits are used for version and variant markers). The probability of two randomly generated UUIDs colliding is roughly 1 in 5.3 × 10^36 — effectively zero for any realistic workload.
Generating one billion UUIDs per second for a century would still give a collision probability of only about 50%. For a collision to matter in practice, you would need to generate IDs at extreme scale within the same namespace, which is not a realistic concern for most applications.
Our UUID generator uses the browser's Web Crypto API (crypto.randomUUID where available, falling back to crypto.getRandomValues) to ensure cryptographic-quality randomness rather than Math.random(), which is not suitable for security-sensitive identifiers.