UUID Generator

A UUID is 128 bits written as 32 hex digits in the familiar 8-4-4-4-12 shape. The promise is that you can mint one on any machine, at any time, without asking anyone, and still never collide with a UUID minted somewhere else. This tool generates version 4 — the random kind.

Version 4 is 122 random bits, not 128

Six of the 128 bits are spoken for. Four encode the version, which is why every v4 UUID has a literal "4" at the start of the third group. Two more encode the variant, which is why the fourth group always begins with 8, 9, a or b. Everything else — 122 bits — is random.

That leaves room for about 5.3 × 10³⁶ values. The number people actually care about is the collision probability, and the birthday bound puts a 50% chance of any duplicate at roughly 2.7 × 10¹⁸ UUIDs. To put that in reach you would need to generate a billion per second for about eighty-five years. In practice, if you are colliding, your random source is broken — not your odds.

Where the randomness comes from matters more than the version

This generator uses crypto.getRandomValues(), the browser's cryptographically secure random source. That choice is not cosmetic. The obvious alternative, Math.random(), is not a CSPRNG: V8 implements it with xorshift128+, an algorithm designed for speed and statistical quality, not for unpredictability. Observe enough of its outputs and you can recover its internal state and predict every value it will produce next.

For a UUID that only needs to be unique, that difference does not matter. It matters enormously the moment a UUID is also expected to be unguessable — a password reset link, an invitation URL, a "secret" document share. Those are exactly the places v4 UUIDs get used as tokens, and a Math.random()-based generator turns them into a vulnerability that no test will ever catch. If you take one thing from this page: check what your UUID library uses before you treat its output as a secret.

The database primary key question

Random UUIDs make excellent identifiers and mediocre clustered primary keys, and it is worth knowing why before you commit a schema. Databases store B-tree indexes in sorted order. Auto-incrementing integers always append to the rightmost page, which is cheap. Random v4 UUIDs land anywhere, so inserts scatter across the whole index, forcing page splits and dirtying pages all over the buffer pool.

It bites hardest in MySQL with InnoDB, where the primary key is the clustered index — the table itself is physically ordered by it, and every secondary index carries a copy of the primary key. A random 16-byte key there is expensive twice over. This is precisely the problem UUID version 7 was standardised to solve: it puts a millisecond timestamp in the high bits, so values sort roughly by creation time and inserts stay near the right edge while keeping enough randomness to remain unguessable. If you want UUIDs as primary keys at volume, v7 or ULID is the modern answer — this tool generates v4, which is the right choice for identifiers that are not also the physical order of your table.

The formats are cosmetic, mostly

Dashes, no dashes, uppercase, braces — all four render the same 128 bits and any sane parser accepts any of them. The braces style comes from Microsoft's GUID conventions and is what you will see in the Windows registry and in COM interfaces. The dashless 32-character form is convenient where length matters, like a URL segment.

One caution: lowercase is what RFC 9562 specifies for output, while parsers are required to accept both cases on input. If you store UUIDs as strings rather than as a native 16-byte type, an inconsistent case can produce two rows that are the same UUID and do not compare as equal. That is a self-inflicted bug, and normalising to lowercase on the way in avoids it.

Common questions