UUID v7 Generator
Time-ordered UUIDs for modern database keys
Every UUID is generated and decoded in your browser using Web Crypto. Nothing is ever uploaded or stored on a server.
Version 7 is the newest UUID version, standardized in RFC 9562 in 2024, and it exists to fix the one real complaint about v4: pure randomness has no order. A v7 UUID opens with a 48-bit Unix millisecond timestamp, then fills the rest with random bits, so UUIDs generated later always sort after ones generated earlier. Same uniqueness guarantees as v4, but usable as a database key without the index fragmentation random IDs cause.
What makes v7 different from v4
Both versions are 128 bits with the same version and variant bits reserved. The difference is what fills the rest. v4 is random from the first bit. v7 spends the first 48 bits on the current Unix timestamp in milliseconds, then fills the remaining bits randomly. That timestamp prefix is what makes v7 sortable: two UUIDs generated a second apart will always compare in the right order, because the part that determines the sort order comes first.
ttttttt-tttt-7rrr-yrrr-rrrrrrrrrrrr └── 48-bit ms timestamp ──┘ └── random ──┘
Why sortable IDs matter for a database
Most databases store rows physically close together when their primary key values are close together. Insert a fully random key like a v4 UUID and every insert lands in a random spot in the index, which fragments it and hurts write performance at scale. Insert a v7 UUID and every new row's key is naturally greater than the last, so inserts land at the end of the index in order, the same access pattern an auto-incrementing integer gives you, but still generated independently on any machine with no round trip to the database.
What the timestamp reveals
Because the timestamp is sitting right there in the first 12 hex characters, anyone who has a v7 UUID can decode roughly when it was created, down to the millisecond. Paste one into the inspector and you'll see this yourself. That's a reasonable trade for most uses, an order ID or event ID being timestamped isn't sensitive, but keep it in mind if you'd rather an identifier not reveal when it was minted. In that case v4 is the better choice.