UUID Generator
Generate UUID v4 and v7 in bulk.
About UUID Generator
Bulk UUID generator (v4 + v7) using the Web Crypto API.
How to use
- 1Pick v4 (random) or v7 (time-ordered).
- 2Set the count (1 to 1000).
- 3Copy a single UUID, all of them, or download as JSON.
A UUID (Universally Unique Identifier) is a 128-bit number that you can generate without coordinating with anyone else and still trust to be unique. That property — distributed, no central authority — is why UUIDs are everywhere modern systems are: primary keys, request IDs, file names, session tokens. This generator produces both UUID v4 (random) and UUID v7 (time-ordered) cryptographically. Pick the version that fits the job, copy or bulk-export, move on.
v4: random, simple, slightly database-hostile
UUID v4 is 128 bits of randomness with 6 bits set aside for version and variant flags. That leaves 122 bits of entropy — uncrackable collision-wise, even at billions of generations per second over decades. Browser implementation is straightforward: pull 16 random bytes from `crypto.getRandomValues()`, mask in the version and variant bits, format as the canonical 8-4-4-4-12 hyphenated hex string. The downside: when used as a primary key in a B-tree-indexed database (Postgres, MySQL), inserts scatter randomly across the index, killing write throughput at scale because each insert lands in a different page.
v7: time-ordered, database-friendly, the modern default
UUID v7 was standardised in RFC 9562 (May 2024) specifically to fix v4's database insert problem. The first 48 bits encode a Unix timestamp in milliseconds. The remaining 74 bits are random (with 6 bits for version and variant). The result is an identifier that is globally unique like v4 but sorts chronologically — so consecutive inserts land in adjacent index pages, which is what databases want. Postgres, MongoDB, ScyllaDB, and modern ORMs (Drizzle, Prisma, SQLAlchemy 2.0) all have first-class v7 support in 2026. For new schemas, v7 is the right default for primary keys.
Other versions, and when not to use them
v1 embeds the generating machine's MAC address — a privacy leak — and a high-precision timestamp. Don't use v1 in anything that touches the internet. v2 is the same idea with DCE security domains and is essentially a historical curiosity; nobody ships v2. v3 and v5 are name-based: hash a namespace UUID and a name to produce a deterministic UUID. Useful for content-addressing or producing stable IDs from external references. v6 is a re-ordering of v1's fields to be time-sortable — superseded by v7 in practice. v8 is a customisation slot reserved for application-defined formats; you almost certainly don't need it.
Bulk generation and export
Generate up to 1000 at a time, copy individually, copy all, or download as JSON or CSV. The bulk path is useful for: seeding test data, pre-generating IDs in offline-first apps where the client needs to produce IDs before reaching the server, populating fixtures for load testing, and one-off ETL where you need stable IDs for a batch of records. Each ID is generated with an independent call to `crypto.getRandomValues()` — no shared state, no collisions even at the high end of the range.
Frequently asked questions
Quick answers to the questions people actually ask about UUID Generator.
What's the difference between UUID v4 and v7?
What's the difference between UUID v4 and v7?
UUID v4 is purely random — 122 bits of randomness, no structure, no timing information. UUID v7 (standardised in RFC 9562, 2024) embeds a Unix millisecond timestamp in the first 48 bits, then random data. This means v7 IDs sort chronologically — critical for database performance, because random IDs scatter inserts across the B-tree index and slow down writes at scale.
Should I use v4 or v7?
Should I use v4 or v7?
v7 for database primary keys, by default. Sortability matters. v4 for security tokens, session IDs, public-facing identifiers where you don't want timing data leaking. Avoid v1 — it embeds the MAC address. v2 is a historical curiosity. v3 and v5 are name-based (hash a namespace + a name) and have specific uses for content-addressing.
Are these UUIDs guaranteed unique?
Are these UUIDs guaranteed unique?
Functionally, yes. v4 collisions would require generating billions of IDs per second for decades. v7's timestamp + 74 bits of randomness make per-millisecond collisions astronomically unlikely. You can safely treat both as globally unique without coordination — that's the whole point.
How are they generated?
How are they generated?
v4 uses `crypto.getRandomValues()` from the Web Crypto API. v7 reads the current time via `Date.now()` and fills the random bits the same way. The full implementation is ~30 lines of JavaScript per version — no library, no server, no dependencies.
Can I generate UUIDs in bulk and export them?
Can I generate UUIDs in bulk and export them?
Yes — set count up to 1000, then copy individually, copy all to clipboard, or download the batch as JSON or CSV. Useful for seeding test data or pre-generating IDs for offline-first apps.
Do I need to worry about RFC 9562 vs RFC 4122?
Do I need to worry about RFC 9562 vs RFC 4122?
RFC 9562 (May 2024) supersedes RFC 4122 and is the current authoritative spec. It defines v6, v7, and v8. v7 is the practical addition — v6 is rarely seen in the wild, v8 is a customisation slot. If you've been using v4 since the 4122 days, your code keeps working — 9562 is additive, not breaking.