A Universally Unique Identifier (UUID) is a 128-bit label standardised by
RFC 9562.
It is represented as 32 hexadecimal digits grouped by hyphens:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
UUIDs are designed so that no central authority is needed to assign them. Any machine can
generate one independently and it will almost certainly never collide with any other.
UUID v7 encodes the current Unix time in millisecond precision in the most-significant 48 bits. The remaining bits hold a version nibble, a 12-bit monotonic counter (to preserve strict ordering within the same millisecond), a variant marker, and 62 random bits. The result is lexicographically sortable: newer UUIDs always sort after older ones, making them an excellent fit for database primary keys, because B-tree pages stay ordered and hot, avoiding the random-write fragmentation caused by v4.
UUID v4 is almost entirely random. Only 6 bits are reserved for the version and
variant markers, leaving 122 bits of entropy. It contains no
timestamp and therefore gives away no information about when or where it was created.
Because it is natively supported by crypto.randomUUID()
in all modern runtimes and browsers, it is the simplest choice for general-purpose
identifiers. Its only drawback is that random inserts can fragment database indexes.
UUID v1 also encodes a timestamp, but uses a quirky 100-nanosecond interval since 15 October 1582 (the Gregorian calendar adoption date) rather than the Unix epoch. The timestamp bytes are spread across the first three fields in a little-endian order that makes v1 UUIDs not naturally sortable. The node field was originally the MAC address of the machine, a privacy concern that led RFC 9562 to recommend randomising it. For new systems, v7 is strictly better.
The intuition comes from the birthday paradox: in a room of just 23 people there is already a 50% chance two share a birthday. Collisions arrive far sooner than most people expect. But UUIDs occupy an astronomically larger space than 365 days.
A UUID v4 uses 122 bits of randomness. The total number of possible v4 UUIDs is:
2¹²² ≈ 5.3 × 10³⁶
The probability p of at least one collision after generating n UUIDs can be approximated as:
p ≈ 1 − e^(−n² / 2N) where N = 2¹²²
To reach even a 50% chance of a single collision you would need to generate:
n ≈ √(2 · ln(2) · N) ≈ 2.7 × 10¹⁸ UUIDs
At a rate of one billion UUIDs per second (far beyond any real workload), it would take roughly 85 years of continuous generation before you had a 50% chance of seeing even one collision across your entire dataset.
UUID v7 has slightly less raw randomness (74 random bits after reserving space for the timestamp, version, and monotonic counter), but the timestamp component actually reduces collision risk in practice: two UUIDs generated at different milliseconds can never collide in their timestamp field, so only UUIDs generated within the exact same millisecond compete on the random portion.
In theory, a broken or exhausted random-number generator could produce repeated outputs. In practice, modern operating systems re-seed the CSPRNG continuously from hardware entropy sources (thermal noise, interrupt timing, etc.), making this essentially impossible. The far more likely source of duplicate IDs in real applications is a bug: for example, accidentally inserting the same UUID twice, or copying data without regenerating identifiers.