What is a UUID v7 Generator
A UUID v7 leads with a 48-bit Unix timestamp in milliseconds, then appends 74 random bits. Because the time is in the most significant position, v7 values sort chronologically when stored as strings or binary — perfect for primary keys and append-only logs.
v7 was standardized in RFC 9562 (2024) alongside v6 and v8. It avoids the MAC-leak concerns of v1 and is simpler to reason about than v6, which is why most new projects choose v7 for sortable IDs.
How to
- Set how many UUIDs you need (1–1000).
- Toggle uppercase, hyphens and braces.
- Press Generate; the first values will share the same leading timestamp.
Use cases
- Primary keys in relational and NoSQL databases (no index fragmentation).
- Sortable public IDs that do not reveal total row counts.
- Event and audit logs ordered by creation time.
Compare UUID v7 Generator with other formats
| Option | When to use |
|---|---|
UUID v7 | Millisecond time + random; modern default |
UUID v6 | v1-style timestamp reordered; legacy-compatible |
UUID v4 | Random; no time component |
Code examples
JavaScript
import { v7 } from 'uuid';
const id = v7(); // '018f6e2a-1c3d-7abc-8def-0123456789ab'Python
from uuid6 import uuid7
id = uuid7()Frequently asked questions
Why is v7 recommended for new projects?
It combines time-ordering (good for indexes) with simplicity. The timestamp is human-readable in the first 12 hex digits, and the random tail keeps collisions negligible.
Do v7 values ever collide?
The 74 random trailing bits make collisions effectively impossible at realistic scale, even for values created in the same millisecond.
Should I store v7 with hyphens?
Keep the canonical hyphenated form for readability and tool compatibility; the sortable property holds either way because the timestamp is in the leading bytes.