What Is UUID v7? The Time-Ordered, Sortable UUID
What is UUID v7 and why is it sortable?
UUID v7 is a 128-bit identifier defined in RFC 9562 in 2024 that puts a Unix millisecond timestamp in the first 48 bits, followed by randomness. Because time is the most significant field, string sorting equals time sorting, so database inserts stay sequential without a central counter.
The 48-bit timestamp at the front
A v7 UUID starts with 48 bits of Unix time in milliseconds, precisely the same clock behind Date.now(). That timestamp occupies the first 12 hex characters, so 0191a2b3-c4d5-7e6f-... already encodes when it was created. The remaining bits are filled with cryptographic randomness, version and variant flags included.
Randomness after time
After the timestamp and the 4-bit version field (0111 for 7), about 74 bits remain random. That balance gives sortable time ordering without sacrificing uniqueness. Two IDs generated in the same millisecond differ only in their random tail, so they stay unique even under high throughput.
- 48 bits: Unix milliseconds since 1970
- 4 bits: version 7
- 12 bits: random with variant
- 62 bits: additional randomness
Monotonic and sequential inserts
Because the most significant bits are time, sorting v7 values as strings is the same as sorting by creation time. Databases that use B-trees, such as PostgreSQL and MySQL with InnoDB, insert new rows at the end of the index instead of randomly throughout it. That keeps writes fast, reduces page splits, and keeps recent rows physically adjacent on disk.
v7 vs v4 vs v1 at a glance
v4 is 122 bits of pure randomness, so string order is random. v1 also embeds time, but it stores the low 32 bits first and includes a MAC address, so lexicographic order does not follow time and it leaks hardware identity. v7 fixes both: timestamp first, no MAC, random tail, and monotonic ordering by design.
- v4: random, not sortable, private
- v1: time-based but not lex-sorted, leaks MAC
- v7: time-ordered, lex-sorted, private
When to pick v7
Choose v7 for primary keys, event IDs, or any record where creation order matters and you insert at high volume. Choose v4 for opaque tokens where ordering must not be visible, and v5 for deterministic IDs derived from a name. If you must match a legacy system that expects v1, keep v1 only for compatibility.
How to generate a v7 UUID
This generator produces v7 entirely in your browser with no upload. In code, the uuid npm package exposes v7 as uuidv7(), Python has uuid7 via third-party libraries, and Java adds UUID v7 in JDK 21 with random plus time construction. Until browsers ship native v7, these local tools are the practical path.
Try it in your browser with our UUID Generator. No upload, no server.
Open UUID Generator →FAQ
Is UUID v7 part of the official spec?
Yes. UUID v7 was added in RFC 9562 in May 2024, alongside the clarification of existing versions. It is the recommended time-ordered UUID going forward.
Is UUID v7 sortable as a string?
Yes. The Unix millisecond timestamp is the most significant field, so lexical sorting equals chronological sorting. That is the core design goal of v7.
Is UUID v7 better than v4?
For database keys and any ID where order matters, yes. For opaque random tokens where you do not want time visible, v4 is still the better choice.
Does v7 leak the exact creation time?
Yes, the first 12 hex characters are the timestamp. If that matters for privacy, use v4 where the bits are random.