What Is a UUID, and When Should You Use One?

A UUID is a 128-bit number used as an identifier. The point of it is not the size but the independence: two machines that have never communicated can each mint one and be confident, to a degree that is easy to quantify, that they will never collide. That single property is what makes UUIDs worth the extra bytes.

The anatomy of a UUID

Written out, a UUID is thirty-two hexadecimal digits split into five groups by hyphens, in the pattern 8-4-4-4-12. The hyphens carry no information and exist purely so a human can read the thing. Two positions inside those digits are reserved: four bits identify the version, and a further two or three identify the variant, which says which specification the layout follows.

3f2504e0-4f89-41d3-9a0c-0305e82c3301
         ^              ^
         version 4       variant bits

Where version 4 gets its randomness

Version 4 fills every bit that is not reserved with random data, leaving 122 random bits. In a browser those bits come from the Web Crypto API, which draws on the operating system entropy pool rather than a predictable pseudo-random generator. This distinction matters more than it appears: a UUID built from Math.random is guessable, and guessable identifiers become access-control failures the moment a URL contains one.

How likely is a collision, really?

The often-quoted figure is that you would need to generate a billion UUIDs per second for around eighty-five years before the chance of a single duplicate reached fifty percent. That number sounds like marketing, but it falls straight out of the birthday problem applied to a space of two to the power of 122. For any workload that is not deliberately adversarial, collisions are not a risk worth designing around.

When a UUID is the wrong choice

The cost of a UUID is not the sixteen bytes. It is the randomness itself. Because consecutive UUIDs land in unrelated places, inserting them into a clustered B-tree index scatters writes across the whole structure instead of appending to the end. On a high-write table this fragments pages and inflates the index far beyond what a sequential key would need.

• Prefer a sequential key when rows are only ever created by one database and write volume is high.
• Prefer a UUID when clients, offline devices or several services must create records independently.
• Consider a time-sortable identifier such as UUIDv7 or ULID when you want both properties at once.

A UUID is not a secret

A common mistake is treating an unguessable identifier as an authorisation mechanism. A version 4 UUID in a URL is genuinely hard to guess, but it will still end up in browser history, server logs, referrer headers and analytics tools. Use one as an identifier, and check permissions separately.