When to use UUID v7

Generate sortable UUID values for storage keys, event IDs, and log correlation when creation order matters.

Friendly to time ordering

UUID v7 includes timestamp-derived bits near the front, making generated order easier to inspect in logs and indexes.

Create test identifiers

Generate sample IDs for fixtures, docs, and local development without leaving the browser.

Not a secret token

A UUID is an identifier, not an authentication secret. Do not use it alone to protect access.

More: how to use it, examples, and common errors

Workflow

How to use it

Generate a new UUID v7 value.
Decide whether sortable IDs fit your table keys, event IDs, or correlation IDs.
For public IDs, design authorization and exposure rules separately.
Choose string or binary storage based on your database and operational conventions.

Examples

Real input and output

Sort order across sequential IDs

Input

Generate three in a row

Output

01923f8a-1c4d-7000-8a3b-9f2e1d4c5b6a
01923f8a-1c51-7000-8a3b-2c7d9e4f1a3b
01923f8a-1c55-7000-8a3b-6b1a8c2d7e9f

The first 12 hex digits are a millisecond timestamp, so plain string sorting preserves creation order.

Troubleshooting

Errors you will hit

Why v4 made your index slow

v4 is fully random, so rows land anywhere in a B-tree index and split pages often. v7 appends in time order, which improves insert throughput and cache hit rate.

The creation time is exposed

A v7 value embeds its millisecond creation time. If a public identifier must not reveal signup or order timing, use v4 instead.

Review

Things to check

Creation time can be inferred

UUID v7 exposes enough information to estimate creation time. UUID v4 may be better when timing should not be visible.

Ordering is not security

Sortable IDs can help operations and indexing, but they do not replace authentication or authorization.

UUID v7 Generator