Generate UUID v1, v4, or v7 in your browser with the UUID Generator. Nothing is uploaded.
Why distributed systems need UUIDs
Auto-increment integers are simple until you have multiple servers, offline clients, or merged datasets. UUIDs let any node generate globally unique identifiers without coordination.
The trade-off with classic random UUIDs (v4) is index performance: random values scatter B-tree and LSM-tree inserts, causing page splits and write amplification on large tables.
Picture an event-log table written by a dozen services. With auto-increment keys you either accept one writer or build an ID allocator, and both add latency. UUIDs remove that step: each service mints its own IDs and merges them later.
A v4 UUID carries 122 random bits, enough that collisions are not a practical concern even with many offline clients.
Side by side
Both versions produce 128-bit identifiers; the difference is what those bits encode. The table below compares the properties that usually decide which one fits a table.
| Property | UUID v4 | UUID v7 |
|---|---|---|
| Sortability | Random, unsortable | Time-ordered, sortable |
| Timestamp | None | 48-bit Unix timestamp (ms) |
| Index locality | Poor on large tables | Good, close to sequential inserts |
| Predictability | Unpredictable | Timestamp portion reveals creation time |
| Standard | RFC 4122 | RFC 9562 |
Anatomy of a UUID v7
A UUID v7 starts with a 48-bit Unix timestamp in milliseconds, followed by a version nibble, a variant field, and random bits.
The timestamp prefix is what makes values sortable: new IDs are usually larger than old ones, so database indexes stay dense and inserts stay fast.
A concrete example: a v7 value minted on 2026-08-17 at 00:00 UTC begins with 01a00d04-9800-7000-8000-…. The first twelve hex characters encode the millisecond timestamp, the 7 is the version nibble, the 8 marks the variant, and the rest is random.
In total, 74 of the 128 bits are random, fewer than v4's 122, but still enough that same-millisecond collisions are not a practical risk.
const uuid = crypto.randomUUID(); // v4// v7 builds on the same random source but prefixes the 48-bit ms timestamp// The browser generator on this site does this for you automatically.Generate UUID v7 in your browser
The generator handles the timestamp and the random bits for you:
- Open the UUID Generator.
- Select version v7 from the version options.
- Choose how many IDs you need, or enable batch mode for a table of values.
- Copy the output and paste it into your migration, seed file, or test fixtures.
Note: If you also need random, unguessable IDs for public URLs, keep v4 in your toolkit and use v7 for sortable keys.
When to use v7 instead of v4
A practical rule: if you sort, page, or merge by creation time, v7 saves you work. If you only need a unique label, v4 is the safer default, and the UUID Generator produces both.
- Primary keys for high-write tables where index locality matters
- Event streams and message queues that benefit from natural ordering
- Distributed databases that merge writes from many nodes
- Public-facing opaque identifiers when the timestamp leak is acceptable
- Cache and deduplication keys where recent entries should expire or collapse together
- Offline-first apps that create records on the device and sync later
Warning: Do not use v7 for tokens, session IDs, or anything that must stay unguessable. The embedded timestamp makes values partially predictable.
FAQ
Q.Are UUID v7 IDs secure?
A.They are unique but not secret. The timestamp prefix reveals roughly when an ID was created, so use v7 for keys and v4 for unguessable identifiers like tokens. The random tail still makes values hard to enumerate; treat a v7 as a key, not a secret.
Q.Do UUID v7 values reveal timestamps?
A.Yes, the first 48 bits encode the creation time in milliseconds. That is the feature that makes them sortable, and it is also the privacy consideration to know about. Because the timestamp sits at the front, sorting v7 values also sorts them by creation time.
Q.Is UUID v7 supported by databases?
A.Most databases store UUIDs as 128-bit values, so v7 works anywhere v4 does. Some databases additionally offer UUIDv7 functions or optimized index handling for time-ordered values. If you plan to generate keys at the database level, check what your engine offers first.
Q.Can two UUID v7 values collide in the same millisecond?
A.Theoretically yes, but 74 random bits make it unlikely: two values from the same millisecond still differ in their random portion. Equal timestamps just make their relative order arbitrary.
Q.Does the browser generator need a server?
A.No. The tool runs entirely in the browser and uses the platform's random source, so it keeps working offline once the page is loaded. Nothing is uploaded.
References
- RFC 9562 – Universally Unique IDentifiers (UUIDs): https://www.rfc-editor.org/rfc/rfc9562
- RFC 4122 – A Universally Unique IDentifier (UUID) URN Namespace: https://www.rfc-editor.org/rfc/rfc4122
- IETF draft uuidrev, the proposal that became RFC 9562: https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/
- MDN Web Docs – crypto.randomUUID(): https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID
Sortable keys, visible timestamps
Use v7 for primary keys on high-write tables and event streams where ordering helps. Use v4 for anything that must stay unguessable.
Generate either in the browser with the UUID Generator.
Quick way to decide: v4 when the ID must stay unguessable, v7 when it should carry order. Both are free to generate here, single or batch.