UUID generator (v4 and v7)
Generate cryptographically random UUID v4 or time-ordered UUID v7 in bulk, choose the output format, and validate or detect the version of any UUID.
- Runs in your browser
- Nothing you enter is sent
- Free, no account
122 random bits. Unpredictable, but scatters across a database index.
Between 1 and 1000 at a time.
- Generated
- 0
- Version
- v4
- Characters each
- 0
How to generate UUIDs
- Pick v4 for pure randomness or v7 for identifiers that sort by creation time.
- Set how many you need, up to 1000 in one go.
- Choose the formatting: hyphens on or off, upper or lower case, braces for a Microsoft-style GUID.
- Pick a layout — one per line, comma separated, or a JSON array — then copy or download the batch.
- Use the Validate tab to check an existing identifier and read its version, variant and embedded timestamp.
The anatomy of a UUID
A UUID is 128 bits, written as 32 hexadecimal digits in five groups: 8-4-4-4-12. Two
positions are reserved. The first digit of the third group is the version, and the
first digit of the fourth group encodes the variant. Everything else depends on the
version.
| Version | How it is built | Sortable | Good for |
|---|---|---|---|
| v1 | 100-nanosecond timestamp plus the machine MAC address | Poorly — the timestamp bytes are in the wrong order | Legacy systems |
| v3 / v5 | MD5 / SHA-1 of a namespace plus a name | No | Deterministic ids derived from a stable name |
| v4 | 122 random bits | No | The general-purpose default |
| v6 | v1 with the timestamp bytes reordered | Yes | Migrating away from v1 while keeping ordering |
| v7 | 48-bit Unix millisecond timestamp, then randomness | Yes | Database primary keys |
| v8 | Whatever you define, within the version and variant bits | Depends | Custom schemes |
v4 or v7 for a database primary key?
This is the decision that actually matters. A v4 UUID is uniformly random, so consecutive inserts land in random positions of a B-tree index. Pages split constantly, the working set stops fitting in memory, and write throughput degrades as the table grows — badly so in storage engines that cluster rows by primary key, such as InnoDB.
A v7 UUID puts the millisecond timestamp in the high bits, so new rows append to the right-hand edge of the index, exactly like an auto-increment integer, while keeping the properties that made you choose a UUID: generated client-side, globally unique, no coordination between services.
The trade-off is disclosure. A v7 identifier tells anyone who sees it when the record was created, to the millisecond, and lets them order two records in time. For an invoice id that is fine. For a password-reset token or an unlisted share link, use v4 — or better, a dedicated random token, since a UUID's dashes and version bits waste six characters of entropy.
How likely is a collision?
A v4 UUID has 122 random bits. By the birthday bound you would need to generate roughly 2.7 × 1018
of them before reaching a 50% chance of a single duplicate — about 85 years of generating a billion per
second. In practice the real risks are a broken random source (a virtual machine cloned with a fixed
seed, or a library falling back to Math.random) rather than the mathematics. This page
always uses crypto.getRandomValues.
Within a single millisecond, the v7 generator here increments a 12-bit counter rather than re-rolling the middle bits, so a batch of 1000 generated in the same instant is still strictly ordered.
Formatting variants you will meet
| Form | Example | Where |
|---|---|---|
| Canonical | 0195c1f4-1b2c-7a3d-9e4f-5a6b7c8d9e0f | RFC 9562, JSON, most APIs |
| Braced | {0195C1F4-1B2C-7A3D-9E4F-5A6B7C8D9E0F} | Windows registry, COM, .NET Guid |
| Compact | 0195c1f41b2c7a3d9e4f5a6b7c8d9e0f | URLs, file names, cache keys |
| Nil | 00000000-0000-0000-0000-000000000000 | A defined "no value" placeholder |
Comparison should always be case-insensitive: the standard says generators must emit lower case but parsers must accept both, and plenty of Microsoft tooling emits upper case.
Questions
What is the difference between UUID v4 and v7?
v4 is 122 random bits with no structure. v7 puts a 48-bit Unix millisecond timestamp at the front and fills the rest with randomness, so v7 values sort chronologically — much kinder to a database B-tree index.
Are these UUIDs random enough to use in production?
Yes. Randomness comes from crypto.getRandomValues, the same cryptographically secure generator used for key material, never from Math.random.
Could two generated UUIDs ever collide?
In practice no. With 122 random bits you would need to generate about 2.7 × 10^18 v4 UUIDs before a 50% chance of one collision. v7 additionally separates values by millisecond.
Does a v7 UUID leak information?
It embeds the creation time to the millisecond, which is visible to anyone holding the identifier. That is usually harmless, but choose v4 where the creation time is itself sensitive.
What does the validator check?
That the string is 32 hexadecimal digits in the 8-4-4-4-12 layout (braces and missing hyphens are tolerated), then reads the version nibble and the variant bits, and decodes the embedded timestamp for v1, v6 and v7.