A version-7 UUID begins with a 48-bit Unix millisecond timestamp followed by random bits, standardised in RFC 9562. Because the time comes first, v7 UUIDs sort in creation order while keeping the global uniqueness of a UUID.

Why use v7 over v4 for database keys?

Random v4 UUIDs scatter writes across an index and fragment B-trees. The time-ordered prefix of v7 keeps inserts roughly sequential, which improves index locality and write performance.

What is the difference between UUID v4 and v7?

v4 is fully random with no ordering, so consecutive values land all over a database index. v7 puts a 48-bit Unix millisecond timestamp first, so values sort by creation time while the random tail keeps them unique. v7 is the better default for primary keys.

Why is v7 better for database primary keys?

Because the time-ordered prefix keeps new rows inserting near the end of the index rather than scattered throughout it. This reduces B-tree page splits and fragmentation, improving insert throughput and cache locality compared with random v4 keys.

How is a UUID v7 structured?

The first 48 bits are the Unix timestamp in milliseconds, followed by a 4-bit version field set to 7, then 12 random bits, the 2-bit variant, and 62 more random bits — 128 bits in total, formatted as the usual hyphenated hex string.

How is v7 different from a ULID?

Both lead with a millisecond timestamp and sort by time. UUID v7 keeps the canonical 36-character hyphenated hex format used everywhere UUIDs are expected; ULID uses a shorter 26-character Crockford base32 string. Choose v7 for UUID compatibility.

Does a batch of v7 UUIDs stay sorted?

Yes. When you generate many at once, the timestamp is nudged forward for each ID so the whole batch is strictly increasing, even for IDs created within the same millisecond.

UUID v7 Generator — Gera Tools

Q: Is anything uploaded?

No. The timestamp and random bits are generated in your browser with Web Crypto and nothing is uploaded.

Sortable UUID v7 generator

A UUID v7 is the newest standard UUID version, defined by RFC 9562, and is designed to be time-sortable. It leads with a 48-bit Unix millisecond timestamp and fills the rest with cryptographic randomness, so a sequence of v7 UUIDs sorts in creation order while keeping the global uniqueness of a UUID. This combination — the ordering of an auto-increment key with the decentralised uniqueness of a UUID — makes v7 the modern default for database primary keys. This tool generates one ID or a sortable batch, all in your browser.

How it works

The 128 bits are arranged so that time comes first:

Bits	Field	Content
48	Timestamp	Unix time in milliseconds
4	Version	Fixed: 7
12	Random	From Web Crypto
2	Variant	RFC 4122
62	Random	From Web Crypto

Because the timestamp occupies the most significant bits, comparing two v7 UUIDs as strings or bytes orders them by creation time. The random portion (74 bits) comes from crypto.getRandomValues, keeping each value unique. When generating a batch, the timestamp is advanced per ID so the batch stays strictly increasing.

Example

A v7 UUID looks like 018f3a2b-1c4d-7e8a-9b0c-1d2e3f4a5b6c. The leading 018f3a2b-1c4d is the millisecond timestamp, the 7 at the start of the third group marks version 7, and the remaining hex is random. Generate three in a row and their leading characters increase, so they sort in creation order out of the box.

Inserts stay roughly sequential, so indexes don’t fragment the way random v4 keys cause them to. The timestamp and random bits are generated in your browser with Web Crypto, and nothing is uploaded.