UUID Versions Compared
| Version | Algorithm | Sortable? | Best for |
|---|
v1 | Timestamp + MAC address | Partially (time-based) | Distributed systems needing time ordering, logging |
v4 | Fully random | No | General purpose — the most common choice for IDs |
v5 | Namespace + name → SHA-1 hash | No | Deterministic IDs for the same input (e.g., URL → UUID) |
v7 | Unix ms timestamp + random suffix | Yes — lexicographically sortable | Database primary keys — monotonically increasing, no fragmentation |
ULID vs UUID
A ULID (Universally Unique Lexicographically Sortable Identifier) encodes a 48-bit millisecond timestamp followed by 80 bits of randomness in Crockford Base32. ULIDs are 26 characters vs 36 for a UUID (or 32 without hyphens), URL-safe by default, and sort correctly as strings. They're an excellent choice for database primary keys when insertion order matters.
UUID v5 (Deterministic)
v5 produces the same UUID for the same namespace + name combination. This is useful when you need a stable UUID for a known entity — e.g., always mapping example.com in the DNS namespace to the same UUID. The standard namespaces are: DNS, URL, OID, and X.500. The output is a SHA-1 hash of the namespace bytes concatenated with the name bytes, then formatted as a UUID with version/variant bits set.
When to Use Which
Use v4 for most cases: session tokens, API keys, object IDs where you don't need order. Use v7 (or ULID) as database primary keys to avoid index fragmentation and enable time-range queries. Use v5 when you need reproducible IDs for the same logical entity. Use v1 only when you need to trace the generating machine (though be aware it leaks the MAC address).
Coming soon for logged-in users: Save generated UUID sets to your history and mark frequently used UUIDs as favorites for quick reference.