Developer
Encoders, converters & dev utilities
UUID v7 Generator — Time-Ordered UUIDs for DB Keys
A version-7 UUID is the modern, time-ordered UUID standardised in RFC 9562 (2024). Its first 48 bits are a big-endian Unix millisecond timestamp, followed by the version nibble (7), a few random bits for sub-millisecond ordering, and the variant. Because the timestamp leads, v7s generated in sequence sort in creation order as plain strings or bytes — which makes them ideal database primary keys. Unlike random v4 keys that scatter across a B-tree index and cause page splits and fragmentation, v7 inserts land at the right edge of the index, preserving write throughput and cache locality. This is why teams are moving new primary keys from v4 to v7. This generator builds v7s from the current millisecond timestamp plus CSPRNG bits, entirely in your browser, with a monotonic tail so a bulk batch stays sortable. Free, no login.
v7 = 48-bit big-endian Unix-millisecond timestamp + version 7 + random tail (RFC 9562, 2024)
- Time-ordered: v7s generated in sequence sort in creation order as strings/bytes
- Ideal for DB primary keys — inserts land at the right edge of the B-tree, avoiding fragmentation
- Contrast: random v4 keys scatter across the index → page splits, worse write throughput
- Version nibble (13th hex digit) is 7; variant (17th) is 8/9/a/b
- Monotonic within the same millisecond so bulk batches stay sortable
- Built from the browser clock + CSPRNG bits, in-browser — no server
Frequently asked questions
What is a UUID v7 and why is it time-ordered?
A UUID version 7 is a 128-bit identifier whose first 48 bits are a Unix timestamp in milliseconds (big-endian), followed by the version marker 7 and random bits. Because the timestamp comes first, v7 values increase over time, so a set of them sorts in creation order. That property — being both unique and roughly sequential — is what makes v7 attractive for database keys and any use case where you want to order records by when their ID was minted. It was standardised in RFC 9562 in 2024.
Why is UUID v7 better than v4 for database primary keys?
Random v4 keys are scattered uniformly, so each insert can land anywhere in a B-tree index, causing page splits, index fragmentation, and poor cache locality — which hurts write throughput as the table grows. v7 keys are time-ordered, so new rows insert at the right (newest) edge of the index, keeping it compact and sequential, much like an auto-increment integer but without a central counter. You keep the global uniqueness and non-guessability benefits of a UUID while regaining the insert performance of sequential keys.
Do v7 UUIDs stay sortable when I generate many at once?
Yes, when generated correctly. Within a single millisecond, multiple v7s share the same 48-bit timestamp, so ordering must come from the random/counter bits that follow. A correct generator makes those bits monotonic within the same millisecond so a bulk batch remains in creation order. This tool applies that monotonic tail, so a batch of v7s you generate together sorts ascending — which is exactly what you want when seeding sequential test data or bulk-inserting rows.