What a UUID v7 contains
A UUID v7, standardised in RFC 9562, starts with a 48-bit Unix timestamp in milliseconds, then 12 bits of sub-millisecond precision or extra randomness, then a 62-bit random tail. The version nibble (position 13) is always 7 and the variant nibble (position 17) is 8, 9, a or b. Because the timestamp leads, IDs generated later always sort after earlier ones as plain text β no database sequence required.
Worked example: 018f3d9c-7b21-7a4e-9c30-6d5f1e2a8b44. The leading 018f3d9c7b21 is the current time in milliseconds, the 7 marks version 7, the 9 marks the variant, and the tail is random. Consecutive v7 UUIDs are monotonic within the same millisecond because a random counter breaks ties, so they append cleanly to a B-tree index instead of scattering. Prefer v7 for primary keys and event logs; prefer random v4 when IDs must reveal nothing about creation time.
How to generate a UUID v7
- Click Generate to mint a time-ordered UUID v7.
- Generate several in a row β they sort in creation order.
- Copy them for sortable primary keys or log IDs.
- Need opaque, order-free IDs? Use the UUID v4 page.
UUID v7 β frequently asked questions
Are UUID v7 values sortable?
Yes. The first 48 bits are a millisecond timestamp, so lexicographic order matches creation order; a random tail keeps concurrent values from colliding.
Does a UUID v7 leak when it was created?
It reveals creation time to millisecond precision. That is usually fine for logs and database keys, but use v4 if the timestamp is sensitive.
UUID v4 or v7 for a database key?
v7: its ordered prefix keeps inserts at the end of the index and avoids the page splits caused by random v4 values. Choose v4 if you need purely opaque IDs.
Runs entirely in your browser: the timestamp and random bits come from your device's clock and crypto.getRandomValues(), never a server.
