Random — 122 bits of cryptographically secure random data.
About this tool
A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122 (superseded by RFC 9562). It is represented as 32 hexadecimal digits grouped by hyphens in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. UUIDs are designed to be generated independently on any machine at any time without a central coordinator, making them ideal for distributed systems, offline-first applications, and any scenario where a globally unique ID is needed without a database round-trip.
UUID v4 is randomly generated — 122 bits are random and 6 bits encode the version (0100) and variant (10). The probability of generating a duplicate v4 UUID is negligibly small: you would need to generate approximately 2.7 quintillion UUIDs to have a 50% chance of any collision. In practice, v4 UUID collision is not a realistic concern even at very large scale. UUID v4 is the most widely used version and is the right choice for the vast majority of use cases.
UUID v7, introduced in RFC 9562 (2024), encodes a millisecond-precision Unix timestamp in the 48 most significant bits, followed by a random sequence number and additional random bits. This makes v7 UUIDs naturally sortable by creation time, which has a significant practical advantage: when used as primary keys in relational databases with B-tree indexes (PostgreSQL, MySQL, SQLite), new records are always inserted at the end of the index rather than at random positions. This dramatically reduces index fragmentation and write amplification compared to random v4 UUIDs.
The database performance argument for UUID v7 over v4 is substantial. A B-tree index on a v4 UUID primary key will fragment as the database grows because each INSERT writes to a random position in the index, requiring frequent page splits. An index on a v7 UUID behaves more like an auto-increment integer index, with sequential writes that keep the index pages densely packed. For large tables in write-heavy workloads, this difference can be significant in terms of both storage and query performance.
UUIDs appear in many contexts beyond database keys: filenames for uploaded user content (to avoid collisions without a central filename registry), correlation IDs in distributed tracing systems, idempotency keys for safe request retry, node identifiers in distributed systems, and session identifiers. When comparing UUID performance to other ID strategies, note that UUIDs are larger than integers (16 bytes vs 4 or 8 bytes) and that this size affects storage, index size, and JOIN performance at very large table sizes.