UUID v4 vs UUID v7
UUID v4 is random. UUID v7 is time-ordered using a Unix millisecond timestamp plus random bits. See when to use each, how they look, and how to generate them in the browser.
v4 is random; v7 is sortable by time
Both are 128-bit UUIDs written as 32 hex digits with hyphens. RFC 9562 defines UUID version 4 as random (122 random bits plus version/variant bits). Version 7 puts a 48-bit Unix timestamp in milliseconds in the high bits, then random data, so values created later usually sort after values created earlier.
Generate either version locally with the UUID Generator. Nothing is uploaded.
How to tell them apart
The version is the first hex digit of the third group (the character after the second hyphen). 4 means v4. 7 means v7. The variant bits sit in the next group and are typically 8, 9, a, or b.
| Version | Third group starts with | Ordering |
|---|---|---|
| UUID v4 | 4 | No time order — random |
| UUID v7 | 7 | Roughly creation-time order |
Example shapes
These are educational samples, not values you should reuse as unique IDs.
v4 9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d
v7 018f1e3c-8b2a-7c11-9e2f-1a2b3c4d5e6f
^ ^
version nibble variant nibble (8–b)When UUID v4 is the better default
Choose v4 when you need an opaque identifier with no embedded timestamp — session IDs, public resource IDs you do not want to leak creation time, or systems that already standardized on v4. Random IDs do not help B-tree indexes stay sequential; that can matter at very large insert rates.
When UUID v7 is useful
Choose v7 when you want unique IDs that still sort approximately by creation time: database primary keys, log correlation, or queues where “newer” should sort after “older” without a separate created_at column. v7 still contains random bits, so it is not a precise clock. Convert the embedded milliseconds with a Unix Timestamp Converter only if you understand they are milliseconds, not seconds — see What Is a Unix Timestamp?.
What neither version is
UUIDs are identifiers, not secrets. Do not treat a UUID as a password or API key. For secrets, use a password / passphrase generator with enough entropy. v7 also does not replace a trusted created_at for legal or billing timestamps — clocks can be wrong, and the UUID is not a signed assertion.
Generate v4 or v7 in the browser
Open the UUID Generator, pick UUID v4 or UUID v7, and copy or batch-generate values. Validate a pasted UUID if you need to confirm version and variant bits before you store it.
Frequently asked questions
- Is UUID v7 better than UUID v4?
- Neither is universally better. v7 is better when you want time-ordered IDs. v4 is better when you want no embedded timestamp. Compatibility with existing v4-only systems also matters.
- Can I extract the time from a UUID v7?
- You can read the 48-bit Unix millisecond field. It is a creation hint, not a guaranteed accurate clock, and it should not replace an explicit timestamp column when you need an audit trail.
- Are UUID v7 values sortable as strings?
- The canonical 8-4-4-4-12 hex form sorts in the same order as the underlying 128-bit value for v7, which is the point of putting time in the high bits. Do not remove hyphens inconsistently if you rely on string sort.
- Should I still use UUID v1 or v6?
- RFC 9562 still documents older versions, but new designs usually pick v4 (random) or v7 (time-ordered). v1 embeds a timestamp and historically used a MAC address; prefer v7 if you specifically want time-ordered UUIDs.