Guide
UUID v4 vs UUID v7: randomness, time ordering, and choosing
Compare UUID v4 and v7, understand which bits carry randomness or time, and choose based on privacy, ordering, and database indexes.
by Tools in a Tab · Published on · Reviewed on
Short answer
UUID v4 uses randomness and does not express when it was generated. UUID v7 places a Unix timestamp in milliseconds in its most significant bits and fills the identifier with randomness, so values are approximately time ordered. Choose v4 for an opaque, widely available identifier; choose v7 when temporal ordering benefits storage or queries and exposing the time is acceptable.
Main differences
| Property | UUID v4 | UUID v7 |
|---|---|---|
| Basis | Random or pseudorandom | Unix time in ms plus randomness |
| Time ordering | No | Yes, through the leading bits |
| Embedded creation time | No | Approximately extractable |
| Version in text | First character of third group is 4 |
It is 7 |
| Current site tool | Available | Not currently available |
In v4, the fixed version and variant fields leave 122 bits for random data. In v7, RFC 9562 assigns the most significant 48 bits to milliseconds since the Unix epoch and leaves 74 bits, apart from version and variant, for randomness or optional monotonicity mechanisms.
When to choose v4
UUID v4 is a sound default when you need identifiers without central coordination. It embeds neither the time nor a machine identity. That does not make it a secret: if an identifier grants access, authorization controls are still required.
Tools in a Tab’s UUID generator generates only v4 using the browser’s cryptographic random source. Do not interpret its results as v7 or as values that can be sorted by creation time.
When to choose v7
The temporal order of v7 can improve insertion locality in indexes and provide approximate ordering without another field. The tradeoff is that the identifier reveals its creation millisecond. If that fact is sensitive or exposes activity patterns, keep v4 or use a separate public identifier.
Two v7 values created in the same millisecond still need a correct implementation for uniqueness and, when required, monotonicity. Do not invent a variant by concatenating a timestamp and random digits. Use an RFC 9562 library and test its behavior when the system clock moves backward.
Quick decision
- Use v4 for opaque identifiers, broad compatibility, and no embedded time.
- Use v7 for new systems where time ordering provides a measured benefit.
- Do not migrate an existing schema just for novelty; review indexes, timestamp exposure, library support, and migration cost.
Both versions address distributed uniqueness. The practical distinction is whether time should be part of the identifier.