How UUID v7 Works

The timestamp portion

UUID v7 begins with a Unix timestamp in milliseconds. Because that timestamp is placed at the beginning of the value, ordinary string sorting usually follows generation time when the UUIDs use the same canonical format.

The timestamp is not metadata stored beside the UUID; it is part of the identifier itself. If you expose the UUID to users or logs, you are also exposing that time signal.

The random portion

After the timestamp and required version/variant bits, UUID v7 uses random data. Good implementations use cryptographic browser or operating system randomness for those bytes.

Randomness is still important. The timestamp alone is not enough because many IDs may be generated in the same millisecond across one or many machines.

Sorting behavior

UUID v7 is designed so newer values normally compare after older values. That makes it more convenient for logs, event tables, and sorted database indexes than a purely random UUID.

Sorting still depends on preserving the normal UUID byte/string layout. If you remove hyphens, uppercase the value, or store it in a UUID-aware database column, ordering should remain consistent. If a system transforms bytes into a custom layout, verify the behavior before relying on it.

What UUID v7 does not guarantee

• It does not prove that an event actually happened at the embedded time.
• It does not replace authorization, signatures, or audit controls.
• It does not hide creation time from people who can read the identifier.
• It does not guarantee perfect monotonic order when clocks move or multiple systems generate IDs concurrently.

FAQ

Related guides