Identifiers
UUID v4 vs v7 vs v5: Which UUID Version Should You Use?
Universally Unique Identifiers (UUIDs) come in many versions, and choosing between v4, v5, and v7 has real consequences for database performance and application correctness. UUID v4 is the most famous — fully random. UUID v7 is time-ordered and increasingly the recommended choice for database primary keys. UUID v5 is deterministic and derived from a namespace and name. Understanding the differences helps you pick the right identifier for the job.
1.UUID v4: The Random Classic
UUID v4 generates identifiers from random bytes (122 bits of randomness plus version and variant bits). Because it is random, v4 UUIDs are globally unique with an astronomically low collision probability and reveal nothing about when or where they were created. This makes v4 the right choice for public identifiers, correlation IDs, and any ID that must not leak information. The downside is that random values are poorly ordered, so inserting them into a clustered index (like a primary key in PostgreSQL or MySQL InnoDB) causes page splits and index fragmentation under heavy writes.
2.UUID v7: Time-Ordered for Databases
UUID v7 embeds a Unix timestamp (millisecond precision) in the high bits and fills the rest with random data. Because the leading bits increase with time, v7 UUIDs are roughly sortable by creation time and insert sequentially into B-tree indexes, dramatically reducing fragmentation compared to v4. UUID v7 became an IETF standard in RFC 9562 and is now the recommended default for new database primary keys, event IDs, and log IDs. It is also lexicographically sortable, which makes it useful for pagination and time-based queries.
3.UUID v5: Deterministic Name-Based
UUID v5 derives a UUID by hashing a namespace UUID plus a name using SHA-1 (RFC 4122). The same namespace and name always produce the same UUID, so v5 is ideal when you need a stable identifier derived from existing data — for example, mapping a customer's email or a file path to a fixed UUID without storing a mapping table. It is also useful for generating identifiers in distributed systems that must be reproducible. The trade-off is determinism: given the namespace and name, anyone can recompute the UUID, so do not use it to hide or protect data.
4.Which Version Should You Choose?
For new database primary keys, event streams, and anything that benefits from sort order, use UUID v7. For public-facing identifiers where you want no time leakage and maximum randomness, use UUID v4. For reproducible identifiers derived from a name, use UUID v5. Avoid UUID v1 (which leaks MAC addresses and timestamps) and UUID v3 (legacy MD5-based) in new designs.
Try the tools
Run these conversions and checks instantly in your browser — no data leaves your device.
Frequently Asked Questions
What is the difference between UUID v4 and v7?
UUID v4 is entirely random, while UUID v7 is time-ordered — it embeds a millisecond timestamp in its leading bits. v7 is the recommended default for database primary keys because it reduces index fragmentation and sorts chronologically.
Are UUID v4 collisions possible?
Theoretically yes, but practically negligible — roughly a 50% chance of one collision only after generating about 2.7 quintillion UUIDs. For almost all applications you can assume uniqueness.
When should I use UUID v5?
Use UUID v5 when you need a deterministic identifier derived from a name — the same input always yields the same UUID. Common uses include mapping emails, paths, or domain names to stable IDs without extra storage.
Can I generate UUID v4, v5, and v7 online?
Yes. Our free UUID generator supports v3, v4, v5, and v7 with bulk generation and one-click copy, running entirely in your browser with cryptographically secure randomness.
More comparisons
Explore side-by-side guides for other developer tools and formats.
View all comparisons