UUID v7 Generator

What is UUID v7?

UUID v7 is a 128-bit identifier whose leading 48 bits are a Unix-millisecond timestamp, making it sortable by creation time while keeping the global uniqueness of any UUID. It is the 2026 recommendation for new work — especially database primary keys — because time-ordered values keep B-tree indexes healthy where random v4 keys fragment them.

This generator implements RFC 9562 §5.7 and adds the §6.2 Method 1 monotonic counter: a dedicated 12-bit counter in the rand_a field guarantees that two v7 UUIDs minted in the same millisecond still sort in the order you generated them. Everything runs in your browser using crypto.getRandomValues() — no server, no logging.

UUID v7 structure

UUID v7 occupies 128 bits laid out by RFC 9562 §5.7:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├─────────────────────────────────────────────────────────────────┤
│                    unix_ts_ms (48 bits)                         │
├─────────────────────────────────────────────────────────────────┤
│ ver(4) │           rand_a (12 bits)                             │
├─────────────────────────────────────────────────────────────────┤
│ var(2) │           rand_b (62 bits)                             │
└─────────────────────────────────────────────────────────────────┘

The first 48 bits are the Unix timestamp in milliseconds. The next 4 bits are the version (0111, producing 7 at string position 13). This generator places a 12-bit monotonic counter in rand_a per RFC 9562 §6.2 Method 1, guaranteeing sort order even for UUIDs generated within the same millisecond. The remaining 62 bits (the rand_b field, after the 2-bit variant) are drawn from crypto.getRandomValues().

Why v7 is preferred for database primary keys

A UUID v4 primary key inserts at a random leaf position in a B-tree index on every write. As the table grows, this causes page splits, increases the working set that must remain in the buffer pool, and means consecutive rows are rarely on the same disk page — making range scans slow. UUID v7’s timestamp prefix eliminates this: rows generated in temporal order insert in index order, so the active insertion region is always the rightmost leaf pages. This is the same property that makes auto-increment integers efficient, without requiring a central sequence.

PostgreSQL 18 adds a native uuidv7() function. Earlier versions, MySQL, SQLite, and most other databases accept any valid UUID string or 16-byte binary value — the storage format is unchanged, only the generation changes.

What UUID v7 discloses

The 48-bit timestamp is always recoverable from the UUID string: take the first 12 hex characters, parse as an integer, and you have the Unix millisecond creation time. Anyone who sees a v7 UUID can determine when the record was created to the millisecond. If two v7 UUIDs are compared, the number of records created between them is also computable from the monotonic counter bits.

This is acceptable for internal primary keys where creation time is not sensitive. It is not acceptable for tokens, share links, invite codes, or any ID that appears in a public URL where timing information should be hidden. Use UUID v4 in those cases.

UUID v7 vs v4

Use v7 for: database primary keys, event IDs, log correlation identifiers, any ID where creation order is useful and safe to expose. Use v4 for: session tokens, share links, password-reset URLs, invite codes — anything where 122 bits of pure randomness is safer than a recoverable timestamp.

The UUID v4 vs UUID v7 comparison works through the database index behaviour and migration path in detail.

If the format itself is new to you, what a UUID is covers the structure and version digits.