UUID v7 Generator (Time-Ordered)

Generate time-ordered UUIDv7 identifiers (RFC 9562) or classic random v4s by hand with Web Crypto. Everything runs in your browser.

Identifiers are generated locally with the Web Crypto API. Nothing ever leaves your device.

Output

The timestamp under each v7 is decoded from its first six bytes — Copy takes only the UUID itself.

How It Works

UUIDv7 is defined by RFC 9562 and this page builds it by hand from crypto.getRandomValues — no libraries. The trick that separates it from v4 is where the bytes go: a wall-clock timestamp is moved to the front of the identifier, so the string's own sort order becomes creation order. The version toggle also lets you mint classic random v4 UUIDs for comparison, and the timestamp printed beside each v7 is decoded back from its first six bytes.

The v7 byte layout
Bytes 0–5 hold the Unix time in milliseconds as a 48-bit big-endian integer — that sorts correctly until the year 10889. Byte 6 starts with the 4-bit version field (0x7) followed by 12 random bits called rand_a. Bytes 7–15 carry the rest: byte 8 begins with the two variant bits (10), and the remaining 62 bits (rand_b) are random. Total randomness inside one millisecond: 74 bits. Rendered in the familiar 8-4-4-4-12 hex groups, a v7 looks exactly like any other UUID.
Lexicographic order is time order
String comparison reads left to right, and the leftmost 48 bits are the clock, so sorting v7 UUIDs alphabetically sorts them chronologically. In a B-tree primary key this means inserts always land on the rightmost leaf: pages fill sequentially instead of every write touching a random page, which keeps indexes compact, caches warm and LSM-tree compaction cheap. A v4 key randomizes that access pattern; a v7 key streams through it.
Where v4 still wins
v4 carries 122 random bits and leaks nothing about when or where an ID was made. For public identifiers, unguessable URLs and security tokens, the timestamp prefix of v7 (an information disclosure, and a smaller random tail) argues for the older format. Use each one for what it was designed for: v7 for ordered keys, v4 for opaque references.

Frequently Asked Questions

When should I use v7 instead of v4?

Reach for v7 when IDs live in a sorted index — a Postgres primary key, a B-tree or LSM-tree table like MySQL InnoDB, RocksDB or DynamoDB sort keys. Because v7s sort lexicographically in the same order they were created, new rows append to the end of the index instead of scattering writes across it. Reach for v4 when the value must be unguessable and time must not leak: public identifiers for URLs and security tokens still favor v4's larger random tail and zero timestamp.

Why do v7 UUIDs sort in time order?

The first 48 bits of every v7 UUID are the creation time — milliseconds since the Unix epoch — written most-significant byte first. Sorting UUID strings compares from the left, so the timestamp dominates the comparison: '0198…' rows always sort before '0199…' rows, and lexicographic order equals chronological order. The random bits that follow only decide the order of UUIDs minted inside the same millisecond.

Is a v7 UUID still collision-safe?

Yes, within the same millisecond: after the 48-bit timestamp and the 6-bit version and variant markers, 74 bits are left random — about 1.9 × 10^22 possibilities per millisecond of creation time. That is far beyond what one machine emits in a millisecond, so collisions remain a theoretical curiosity. If you need strict same-millisecond monotonicity guarantees, use a server library that implements RFC 9562's optional monotonic-count scheme; this browser tool relies on the random bits.

Do generated IDs have different timestamps?

Each UUID is stamped with the clock at the moment it is created, so batches generated in one click share a millisecond very often — the browser loop runs faster than the clock ticks. That is normal and harmless: the timestamps shown next to the IDs are real, and the random tail keeps every ID in the batch distinct.

Is anything uploaded to a server?

No. The identifiers are assembled in your browser from the Web Crypto API and your system clock. Nothing is transmitted, stored or logged anywhere, and the batch disappears when you close the tab.