UUID v7 Generator

Runs locally

Time-ordered UUIDs (RFC 9562) that sort by creation time.

Generated

How many (max 1000)

Uppercase

IDs made in the same millisecond still sort in the order they were generated: rand_a works as a counter.

Bit layout

The RFC 9562 example, field by field.

017f22e2-79b0-7cc3-98c4-dc0c0c07398f

Field	Bits	Meaning
`unix_ts_ms`	48	Milliseconds since 1970-01-01 UTC, big-endian — here 0x017f22e279b0 = 1645557742000 = 2022-02-22T19:22:22.000Z
`ver`	4	Always 0111 — the "7"
`rand_a`	12	Random, or a counter for ordering within one millisecond
`var`	2	Always 10 — the RFC 9562 variant
`rand_b`	62	Random

v4 or v7?

	UUID v4	UUID v7
Contents	122 random bits	48-bit ms timestamp + 74 random bits
Sort order	Random	Creation time
B-tree index inserts	Scattered across the index	Appended near the end
Reveals creation time	No	Yes, to the millisecond
Collision resistance	2¹²² values	2⁷⁴ per millisecond
Support	Everywhere	Newer libraries; PostgreSQL 18 uuidv7()

Extract the timestamp

Paste any UUID v7 (or v1, v6, ULID) to read the time it was created.

Valid UUID v7 — time-ordered (Unix milliseconds)

Canonical: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f
Variant: RFC 9562 (the standard one)
Created: 2022-02-22T19:22:22.000Z

Guide

Why UUID v7 exists: random keys are hard on indexes

Databases store primary keys in a B-tree, which works best when new keys arrive in order and land at the end. A random UUID v4 lands anywhere, so each insert may load a different page, split it, and leave the index fragmented and larger than it needs to be. On a table with millions of rows that shows up as slower inserts and more I/O. UUID v7, standardised in RFC 9562 in 2024, keeps what makes UUIDs useful — generated anywhere without coordination, practically unique — and makes them roughly sequential.

The layout is simple. The first 48 bits are the Unix timestamp in milliseconds, big-endian, so the leading hex digits are the time. Then come the 4-bit version (7), 12 bits called rand_a, the 2-bit variant (binary 10), and 62 random bits. RFC 9562 lets rand_a act as a counter within one millisecond; this generator does that, so a thousand IDs made in the same millisecond still sort in the order they were created. The time is readable by anyone, which matters if creation time is sensitive; the Timestamp Converter turns it into a date.

Database support is arriving: PostgreSQL 18 has a built-in uuidv7() function, and earlier versions store v7 in the ordinary uuid type, generated by the application. MySQL and MariaDB store it as BINARY(16) — do not use UUID_TO_BIN(…, 1), whose byte swap exists for v1 and would scramble the order of v7. SQL Server sorts uniqueidentifier by its last bytes first, so v7 does not help its clustered indexes; a sequential key suits it better.

UUID v7 (RFC 9562 example)

017f22e2-79b0-7cc3-98c4-dc0c0c07398f

Decoded

unix_ts_ms  017f22e279b0 = 1645557742000
            = 2022-02-22T19:22:22.000Z
ver         7
rand_a      cc3
var         10 (the "9" in 98c4)
rand_b      18c4dc0c0c07398f (62 bits)

The first 12 hex digits are the millisecond timestamp — sort v7 strings and you have sorted by time.

Where people get caught

It leaks the creation time

Anyone who sees a v7 can read when it was generated. Use v4 for IDs that are public and where timing is sensitive, such as invitation links.

Clock skew between servers

Ordering is only as good as the clocks. IDs from two machines whose clocks differ by a second interleave by that second; that is still far better for an index than random keys.

MySQL UUID_TO_BIN swap flag

The swap flag reorders v1 time fields. Applied to v7 it moves the timestamp away from the front and destroys the ordering. Store v7 bytes as they are.

Parsing the time from the wrong digits

Only the first 48 bits (12 hex digits, ignoring the hyphen) are time. Including the version digit in the number gives a date thousands of years out.

About UUID v7

How it works in 4 steps · 4 common use cases · 4 questions answered

How it works

1.Choose how many v7 UUIDs you need and press Regenerate.
2.Read the bit layout of the first one, field by field.
3.Compare v4 and v7 in the table to choose a key type.
4.Paste any v7 into the extractor to read its timestamp.

Common use cases

•Choosing a primary-key format for a new PostgreSQL table
•Replacing v4 keys that fragment a large index
•Reading when an order or event was created from its ID
•Generating sortable IDs for fixtures and event logs

FAQ

What is UUID v7?

A UUID whose first 48 bits are the Unix time in milliseconds, followed by the version, the variant and 74 random bits. It is defined in RFC 9562 and sorts by creation time.

Should I use UUID v7 as a primary key?

Usually yes for PostgreSQL and MySQL tables with many inserts: v7 keys keep B-tree indexes compact. Prefer v4 when the creation time must not be visible.

Are UUID v7s unique if two are made in the same millisecond?

Yes. 74 bits are random, and this generator also uses rand_a as a counter within a millisecond, so IDs are unique and stay in generation order.

How do I get the timestamp out of a UUID v7?

Take the first 12 hex digits, read them as a hexadecimal number, and you have milliseconds since 1970. The extractor on this page does it for you.