UUIDs, generated in bulk

A UUID is 128 bits, normally written as 32 hexadecimal characters in five hyphen-separated groups. The hyphens are purely presentational. The underlying value is the 128 bits, which is why databases can store one in 16 bytes rather than the 36 characters the text form occupies.

Two small fields inside those bits are reserved. Four bits identify the version, and two or three bits identify the variant. In the canonical text form the version is always the first character of the third group, which makes it readable at a glance.

Several versions exist, and they solve genuinely different problems. Most applications need version 4 or version 7.

A version 4 UUID has 122 random bits, giving roughly 5.3 undecillion possible values. The probability of a collision follows the birthday problem rather than simple division, so the intuition that "there are lots of them" understates the safety margin considerably.

To reach a one in a billion chance of a single duplicate, you would need to generate around 103 trillion UUIDs. At a million per second that takes over three years of continuous generation.

The realistic failure mode is not mathematical, it is a weak random source. A UUID generated from a poorly seeded pseudo-random generator can repeat readily, which is why generation should always use a cryptographic source. This tool uses the browser crypto API rather than Math.random for exactly that reason.

Using random UUIDs as primary keys has a well-documented cost. Most relational databases store rows in a B-tree ordered by primary key. Sequential integers append to the rightmost page, which stays in memory and fills neatly. Random UUIDs scatter inserts across the whole tree, so pages split constantly, cache hit rates fall, and the index grows larger than it needs to be.

The effect is invisible on small tables and pronounced on large, write-heavy ones. There are three common ways to avoid it.

Because version 4 UUIDs are unguessable, they are sometimes used as capability tokens: an unlisted URL containing a UUID that anyone holding the link can access. That works, but only while the link stays private, and links leak in predictable ways.

URLs appear in browser history, in Referer headers sent to third-party sites, in server access logs, in analytics tools, in chat previews that fetch the page, and in anything that syncs browser tabs between devices. None of those places is a secret store.

For anything that genuinely needs protecting, use an identifier alongside an access check rather than an identifier as the access check. UUIDs are excellent at being unique; they were never designed to be credentials.

The canonical text form is lowercase, but uppercase is equally valid, and Microsoft tooling frequently wraps the value in braces. String comparison between systems that disagree on case will report two identical UUIDs as different.

Normalise on input rather than trusting the source. Strip braces, lowercase the string, and compare the 16 bytes rather than the text wherever the language makes that convenient. If you store UUIDs as text, apply the same normalisation before writing so the stored form is consistent.