Practical guide · verified against the real thing
UUIDs explained: the 128-bit answer to 'what do I call this?'
In one line: Unique identifiers without a central authority: what a UUID encodes, why version 4's randomness works, and when a random ID is the wrong choice.
Every database row, uploaded file, payment request and analytics event needs a name. Ask two servers to number things 1, 2, 3… and one day they will hand out the same number at the same moment. A UUID (universally unique identifier) sidesteps the whole coordination problem: a 128-bit value generated independently anywhere, whose chance of colliding with anything ever generated before is, for practical purposes, zero.
Reading one
The canonical form is 32 hexadecimal digits in five groups: 8-4-4-4-12. Two of those digits carry structure, and they are worth learning to read: character 13 is the version (how this UUID was generated) and character 17's high bits are the variant (which flavour of UUID layout). A version-4 UUID — the random kind this site's UUID generator produces — shows a 4 in the version slot and an 8, 9, a or b in the variant slot.
The versions that matter
Version 4 is the default of the modern web: 122 of its 128 bits come from a cryptographic random source. No coordination, no sequence to guess, safe to generate on any machine at any rate — that is why APIs, clients and distributed systems hand out v4 UUIDs freely. Version 1 embeds a timestamp and the machine's hardware address: historically important, increasingly avoided because it leaks information. The 2024 revision of the standard (RFC 9562, which obsoleted the 2005 original, RFC 4122) formalised newer flavours — most usefully version 7, which encodes a millisecond timestamp in the leading bits with random low bits: time-ordered, so UUIDs sort naturally by creation in a database index, fixing v4's one real weakness (random IDs scatter across an index and bloat it).
When not to use one
A UUID is an identifier, not a security measure: a v4 ID is unguessable in practice, but if access control matters, unguessability must never be the only gate — treat capability URLs built on UUIDs as convenience, and put real authentication behind anything sensitive (the same layering as proper 2FA). And inside a single small database, plain sequential integers remain perfectly fine — UUIDs buy you independence between systems, and if you have only one system, you are paying storage and index cost for nothing.
The collision math, stated honestly rather than as trivia: you would need to generate billions of v4 UUIDs per second for a century to have a coin-flip chance of one collision. The failure mode of UUIDs is not duplication — it is copying an ID from a test environment into production, or reusing one as a "secret". Those are process failures, and no bit-layout fixes them.
Sources
Next