v4 and v7 solve different problems
UUID v4 is 122 bits of randomness. It carries no information about when or where it was created, which is exactly what you want for public identifiers, session tokens and anything an attacker should not be able to guess or enumerate.
UUID v7, standardised in RFC 9562 in 2024, puts a 48-bit Unix millisecond timestamp in the leading bits and fills the rest with randomness. The result still looks like an ordinary UUID but sorts chronologically as a string, which makes it a far better database primary key.
Why v7 is faster as a primary key
Databases store rows in B-tree indexes. Inserting a random v4 as a clustered primary key scatters writes across the whole index: pages split, the working set stops fitting in memory, and insert throughput degrades as the table grows. This is the well-documented index fragmentation problem with UUID keys.
Because v7 values increase over time, new rows land at the right edge of the index — the same access pattern as an auto-increment integer. You keep the operational advantages of UUIDs (generate on the client, merge datasets without collisions, no central sequence) without paying the write penalty.
The tradeoff is that v7 leaks the creation timestamp to anyone holding the identifier. For an internal primary key that is usually fine. For a password-reset token it is not.
Are collisions something to worry about?
In practice, no. With 122 random bits, you would need to generate roughly 2.7 × 10^18 v4 UUIDs before reaching a 50% chance of a single collision. Generating a billion per second, that is over eighty years.
The realistic risk is not mathematics but bad randomness. UUIDs built on Math.random, on a poorly seeded PRNG, or on a device with an unseeded entropy pool at boot have collided in the wild. This tool uses crypto.getRandomValues, the browser's cryptographically secure generator.
Formats you may run into
The canonical form is 36 characters, lowercase, hyphenated: 8-4-4-4-12. RFC 9562 specifies lowercase output, though parsers must accept uppercase input.
Microsoft ecosystems often render GUIDs in braces ({...}) or uppercase. The dashless 32-character form shows up in URLs and as database column values where the hyphens are stripped to save space. All three are the same 128 bits — only the presentation differs.