UUID Generator
Generate UUID v4 (random) and UUID v7 (time-ordered) identifiers in bulk.
A Universally Unique Identifier (UUID) is a 128-bit value used to identify information without a central authority. You can generate a UUID on a laptop in Tallinn, another on a server in São Paulo, and another on a phone in Tokyo, and they will not collide — not because anyone coordinated, but because 128 bits is enough randomness that accidental duplicates are astronomically improbable. This tool generates UUIDs in your browser using the Web Crypto API, in bulk, with full support for both the classic v4 (random) format and the newer v7 (time-ordered) format that is becoming the default for database primary keys.
Quick version reference
The UUID standard (RFC 9562, updated 2024) defines eight versions. Two matter in practice today:
| Version | Basis | Best use |
|---|---|---|
| v4 | Pure randomness | General-purpose IDs, tokens, correlation IDs |
| v7 | Unix timestamp + randomness | Database primary keys, event IDs, anything sortable |
Older versions (v1, v3, v5, v6) still exist — v1 embeds a MAC address and timestamp, v3/v5 are hashes of a namespace — but v4 and v7 cover virtually every modern use case.
UUID v4 in detail
Format: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, where the 4 marks the version and y is one of 8, 9, a, b (the variant bits). Everything else is random — 122 bits of cryptographic randomness in total.
Collision probability. To have a 50% chance of generating two identical v4 UUIDs, you would need roughly 2.71 × 10¹⁸ generated values (the birthday paradox applied to a 122-bit space). If you generated one billion v4 UUIDs per second, it would take about 85 years to reach a 1% collision probability. For any realistic application, collisions are not worth accounting for.
Trade-off. Because v4 is pure randomness, consecutive values are not related. When used as a database primary key in a B-tree index (PostgreSQL, MySQL’s InnoDB), each insert lands in a random spot in the index — which causes page splits, cache misses, and worse performance than a monotonically increasing key.
UUID v7 in detail
Format: tttttttt-tttt-7xxx-yxxx-xxxxxxxxxxxx, where the first 48 bits are a Unix timestamp in milliseconds. The remaining bits are random.
Benefits.
- Time-ordered. Sort v7 UUIDs and you get them in roughly creation order.
- Index-friendly. Inserts land at the “hot” end of a B-tree index, avoiding the random-write penalty of v4.
- Leak-aware. The timestamp reveals when the UUID was generated, which is almost always what you want for logs and analytics, but be aware if the creation time is sensitive.
When to pick v7. Any identifier that lives in a relational database (id columns in PostgreSQL, MySQL, SQL Server), any event stream where ordering matters, any cache key where you care about eviction by age. If you do not need ordering and want zero information leakage, v4 remains fine.
Why UUIDs instead of auto-incrementing integers?
- Decentralized generation. Clients, microservices, and offline apps can mint IDs without consulting a central database. A user drafting a message offline can generate the message’s ID immediately and sync it later without conflict.
- Harder to enumerate. Sequential integers expose your growth (
/users/500001tells anyone you have 500K users) and invite URL-guessing attacks. UUIDs are unguessable. - Merge-safe. Databases with UUID primary keys can be combined without renumbering. Two Postgres instances can each generate IDs and later replicate into one without conflict.
- Language-agnostic. Every modern language has a standard library or well-maintained package for UUIDs.
The cost: UUIDs are 16 bytes instead of 4 or 8, index storage is larger, and raw lookup performance is slightly lower. For most applications, that cost is trivial next to the operational benefits.
How to use this tool
- Pick a version — v4 for general use, v7 for database keys and event IDs.
- Choose a quantity — generate one at a time or up to 100 at once for bulk seeding.
- Copy individually by clicking a value, or use Copy all to grab the whole list as newline-separated lines suitable for a migration script, a CSV, or a configuration file.
Worked example: choosing v4 vs v7 for a new table
You are designing an orders table that will receive ~1,000 inserts per second at peak.
- v4: Each insert goes to a random leaf of the B-tree, causing many cache misses and page splits. Throughput drops, and bulk imports take noticeably longer.
- v7: Consecutive inserts cluster at the end of the index. Cache behavior is similar to an auto-incrementing integer. Throughput stays high.
For this workload, pick v7. The 48 bits of timestamp also give you free “created-at” information you can recover from the ID itself.
Frequently asked questions
Will two random UUIDs ever collide?
Statistically, no. Even generating a trillion v4 UUIDs per second for a century keeps the collision probability well below 10⁻⁹. For any normal application, assume uniqueness without checking.
Why is there a 4 or 7 in a fixed position?
Those are the version bits, required by the spec so any UUID parser can tell which scheme produced it. The y character (third position of the fourth group) holds the variant bits that identify the broader UUID family (RFC 9562 in nearly all modern cases).
Is UUID v7 supported in my database and language yet?
As of 2026, yes for most major ecosystems. PostgreSQL 18 added a native uuidv7() function. MySQL 9 supports it via a helper. Java, .NET, Go, Rust, Python, Node.js, and Ruby all have well-maintained v7 libraries; many web frameworks default to v7 for new tables.
Can I parse the timestamp out of a v7 UUID?
Yes. The first 48 bits (first 12 hex characters after stripping dashes) are a big-endian Unix millisecond timestamp. Decoding it gives you the creation time with ~1 ms resolution.
What are ULIDs and are they the same as UUID v7?
ULIDs are an earlier proposal for time-ordered, lexicographically sortable IDs. They predate v7 and use a different encoding (Crockford Base32) and layout. Functionally they solve the same problem; UUID v7 is now the standardized choice and compatible with the existing UUID ecosystem.
When should I stay with v4?
When you need an identifier that reveals nothing about creation time (anti-enumeration tokens, opaque user IDs that shouldn’t leak signup order), when working with legacy systems that only accept v4, or when you just want maximum entropy without any structure.
Privacy note
All UUIDs are generated client-side using crypto.getRandomValues(). Nothing ever leaves your device; no identifier you generate here is seen or logged.