Press Generate to mint RFC 9562 UUID v7 identifiers: a 48-bit millisecond timestamp, then 74 random bits, so the IDs sort by creation time as plain strings. A batch of 1000 stays monotonic via a 12-bit counter. Use v7 for database primary keys; use v4 when creation time must stay private. Minted on this device.
Press Generate to create a UUID.
Runs in this tab · nothing is uploaded · Verify in 10 seconds →
A version 7 UUID starts with a 48-bit Unix millisecond timestamp, followed by the version nibble 7, 12 bits of rand_a, the 2-bit variant and 62 bits of rand_b, 74 random bits in all (12 + 62), inside the same 128-bit, 36-character frame as v4. Because the timestamp comes first and fixed-width hex keeps numeric order, v7 IDs sort by creation time as plain strings. Press Generate below; each ID is assembled from Date.now() and crypto.getRandomValues() on your device.
Two numbers follow from the layout. 48 bits of milliseconds cover 2⁴⁸ ≈ 2.8 × 10¹⁴ ms, or 8,919 Julian years (2⁴⁸ ÷ 31,557,600,000 ms per year), so the timestamp field overflows on 2 August 10889. And 74 random bits give 2⁷⁴ ≈ 1.9 × 10²² distinct values per millisecond: a batch of 1000 minted in the same millisecond has 1000 × 999 ÷ 2 = 499,500 pairs, for a collision probability near 499,500 ÷ 2⁷⁴ ≈ 2.6 × 10⁻¹⁷.
If a v7 batch does not sort into generation order, the generator is skipping RFC 9562 section 6.2: this page uses rand_a as a 12-bit counter, reseeded below 2¹¹ whenever the millisecond changes and incremented for every further ID in that millisecond, so sorted output equals generation order. If the third group starts with 4 instead of 7, you generated v4: switch the version toggle above. If the timestamp decoded from the first 12 hex digits looks wrong, suspect the device clock: v7 trusts Date.now(), so a machine set to the wrong time mints IDs from that wrong time. A count outside 1 to 1000 is clamped to the nearest limit.
Use v7 for primary keys and any ID that will be indexed or sorted: rows insert in timestamp order, so B-tree pages stay hot and ORDER BY id approximates creation order. Avoid it where the creation time must stay private (password-reset tokens, public share links) and use v4 there.
This page is a focused view of theUUID Generator (v4 & v7): GUID Generator, which has the full set of options.
The first 48 bits are the Unix millisecond timestamp, big-endian, and a fixed-width hex string sorts the same way the number does. Within one millisecond this generator keeps order with a 12-bit counter in the rand_a field, per RFC 9562 section 6.2.
Take the first 12 hex digits (skip the hyphen) and parse them as a hex integer: parseInt(id.replace(/-/g, '').slice(0, 12), 16) gives Unix milliseconds. Paste that into the timestamp tool to see the date.
Yes, that is the case it was designed for. Time-ordered keys append to the end of a B-tree index instead of scattering across it, which is why PostgreSQL 18 ships uuidv7(). The only trade-off is that anyone holding the ID can read its creation time.
No. A v7 UUID is 16 bytes of arithmetic: 6 bytes of timestamp, version and variant markers, and 74 random bits from crypto.getRandomValues(). This page builds them in your browser; nothing is uploaded.