UUID Generator

Generate cryptographically random version 4 UUIDs in bulk, with optional uppercase, braces or hyphen-free formatting.

How to use this calculator

  1. 1Choose how many you need and in which format.
  2. 2Copy the block — every UUID is on its own line.

How the calculation works

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where x is random hex and y is one of 8, 9, a, b
4
The version field, fixed at 4 for random UUIDs
y
The variant field — the top two bits are fixed to 10

128 bits total, of which 6 are reserved for the version and variant markers, leaving 122 bits of randomness.

The hyphens are purely conventional formatting; the underlying value is 16 bytes.

Other versions exist: v1 embeds a timestamp and MAC address, v5 hashes a namespace and name, and v7 embeds a sortable timestamp. Version 4 is the right default when you just need an unguessable unique identifier.

Worked example

A single standard UUID

  1. 1.16 random bytes are generated from the cryptographic random source.
  2. 2.Byte 6 has its high nibble set to 4, marking it as version 4.
  3. 3.Byte 8 has its top two bits set to 10, marking the RFC 4122 variant.
  4. 4.The bytes are rendered as hexadecimal and grouped 8-4-4-4-12.

Result: A value like 3f2504e0-4f89-41d3-9a0c-0305e82c3301

What a UUID is and the problem it solves

A UUID — Universally Unique Identifier — is a 128-bit value designed to identify something without needing a central authority to hand out the next number. Traditional auto-incrementing IDs work fine on a single database, but they fall apart the moment two systems need to generate IDs independently and later combine their data: two databases can easily both produce row #4521, and now there’s a collision to resolve by hand. A UUID sidesteps the coordination problem entirely — any machine, offline or online, can generate one that will not collide with an ID generated anywhere else, without asking permission or checking in with anyone first.

The different versions, and what makes v4 different

UUIDs come in several versions, each trading off predictability for a different property. Version 1 embeds the generating machine’s network address and a timestamp, which makes it roughly sortable by creation time but leaks information about the machine that made it. Version 5 is deterministic — it hashes a namespace and a name, so the same input always produces the same UUID, useful for generating a stable ID from something you already have. Version 7, a more recent addition, embeds a millisecond timestamp at the front of the value so UUIDs sort roughly in creation order while still being unpredictable in the remaining bits.

Version 4, the one this tool generates, is the simplest of the four: 122 of its 128 bits are filled with random data (the remaining 6 mark the version and variant), and nothing about a v4 UUID reveals when or where it was created. That randomness is also why it is the right default whenever you just need an unguessable, uncoordinated unique ID and don’t need it to sort or encode any other information.

Where distributed systems rely on UUIDs

The ability to generate a unique ID without checking in with a central system shows up constantly in distributed and offline-first software:

  • Distributed databasessystems that shard or replicate data across many nodes need IDs that won’t collide when two nodes insert a record at the same instant — a UUID makes that safe without a coordination round-trip.
  • Request and trace IDsa request entering a system is usually tagged with a UUID immediately, so every log line and downstream service call touching that request can be tied back together, even across services that share no database.
  • Offline-first appsa mobile app that lets you create records while offline needs to assign IDs before it has ever talked to a server; UUIDs let it do that safely, with no risk of colliding with an ID assigned by another device once everything eventually syncs.
  • API resource identifiersmany public APIs expose UUIDs as the public ID for objects rather than a raw database row number, partly because they don’t reveal how many records exist or leak internal ordering.

What UUIDs don’t guarantee

A couple of common assumptions are worth correcting:

  • “Universally unique” is practical, not mathematicala version 4 UUID is only unique in the sense that a collision is astronomically unlikely, not impossible by definition. With 122 random bits, the odds of any collision only become non-negligible after generating on the order of a quintillion UUIDs — a threshold no real system reaches, but it is a probability, not a guarantee.
  • A UUID is not automatically a secure tokena version 4 UUID generated with a proper cryptographic random source is unpredictable and fine to use as, say, a session identifier — but a v1 UUID leaks a timestamp and MAC-derived data, and neither version is designed or vetted as a cryptographic secret the way a dedicated token or key is.
  • Randomness fragments database indexesbecause v4 UUIDs are random, inserting them as a primary key scatters new rows across a B-tree index rather than appending to the end, which shows up as real, measurable write-performance cost in high-throughput clustered-index databases — a problem UUIDv7’s timestamp prefix specifically exists to solve.

What this assumes, and where it stops

Assumptions

  • The browser provides a cryptographically secure random source, which every current browser does.

Limitations

  • Version 4 UUIDs are not sortable and are poor primary keys in databases that cluster on the index, because random inserts fragment B-trees. UUIDv7 or a sequential ID is usually better there.
  • Only version 4 is generated. Versions 1, 5 and 7 serve different purposes and need additional inputs.

Common questions

Can two UUIDs ever collide?

In principle yes, in practice no. With 122 random bits you would need roughly 2.71 × 10¹⁸ UUIDs before reaching a 50% chance of any collision. Generating a billion a second, that takes about 85 years. Collisions from a correct implementation are not a practical concern.

Is a UUID the same as a GUID?

Effectively yes. GUID is Microsoft’s name for the same 128-bit identifier, sometimes written in braces. They are interchangeable in every practical sense.

Should I use UUIDs as database primary keys?

It depends on your database. Random v4 UUIDs scatter inserts across the index, causing page splits and fragmentation in clustered-index engines like MySQL InnoDB. UUIDv7, which embeds a timestamp prefix, keeps inserts sequential and avoids most of that cost.

Sources

Formula and content last reviewed on .

Results are estimates for information only, not professional advice.

Report an error

Tools people commonly use alongside the uuid generator.

See all developer tools calculators →