The Improbable History of the UUID
· 9 min read
In the time it took you to read this sentence, computers around the world minted a few million brand-new names — and not one of them checked with anyone first. No central registry, no coordination, no "is this taken?". Each machine simply rolled 128 bits and walked away certain, to a mathematical near-certainty, that nothing else in the universe shares that name.
That name is a UUID — a universally unique identifier — and the story of how it works is stranger than it looks. It involves a dead workstation company, a papal calendar reform from 1582, a virus author betrayed by his own network card, and one of the most satisfying probability results in computing.
The problem: naming things without a phone call
Before networks, uniqueness was easy. A database handed out row IDs one at a time: 1, 2, 3. One counter, one machine, no ambiguity.
Networks broke that. In the early 1980s, Apollo Computer — a Massachusetts workstation maker that competed with Sun before being swallowed by Hewlett-Packard — was building the Network Computing System, a framework where objects lived on many machines at once. Every object needed a name, and no machine could be required to ask another machine for one. A network where creating a file means a round-trip to a naming authority is a network that fails whenever that authority does.
Apollo's answer was radical: make the namespace so large, and the naming scheme so careful, that machines could pick names independently and still never collide. Their design — a 64-bit identifier, later widened to 128 bits — was adopted by the Open Software Foundation's Distributed Computing Environment (DCE) in the early 1990s, picked up by Microsoft as the GUID that still riddles the Windows registry today, and eventually standardized by the IETF as RFC 4122 in 2005.
The format has not changed since: 128 bits, written as 36 characters of hex in five groups.
8f14e45f-ceea-4a67-8c3d-1b2a9d3f5e7c
└──8───┘ └─4─┘ └─4─┘ └─4─┘ └───12───┘
A handful of those bits are bookkeeping — a version number and a variant marker — and the rest is payload. What goes into the payload is where the history gets interesting.
Why every classic UUID begins in 1582
The original design, now called version 1, filled the payload with two things a machine already knows without asking anyone: what time it is, and who it is.
The "what time" part is a 60-bit counter of 100-nanosecond ticks. But ticks since when? Unix time counts from 1970. UUIDs count from 15 October 1582 — the day Pope Gregory XIII's calendar reform took effect and ten days vanished from October.
The reason is charmingly pragmatic: the designers wanted a timestamp that could faithfully represent any date in the calendar system we actually use, so they anchored it to the moment that calendar began. As a bonus, 60 bits of 100-nanosecond ticks lasts about 3,650 years, so version-1 UUIDs won't roll over until roughly the year 5236 — someone else's problem in the purest engineering sense.
The "who" part was the machine's 48-bit MAC address — the burned-in serial number of its network card, already guaranteed unique by the hardware industry's own registry. Time says no other UUID from this machine, the MAC says no other machine, and together they promise global uniqueness without a single network packet.
It was elegant. It was also a privacy time bomb.
The virus that signed its own confession
Embedding your network card's serial number into every identifier you generate means every identifier you generate points back at your hardware. In the 1990s, Microsoft Office quietly embedded GUIDs — MAC address and all — into Word and Excel documents as internal metadata.
In March 1999, the Melissa virus tore through the early internet, mass-mailing itself from infected Outlook installations, forcing companies like Microsoft and Intel to shut down their email systems. The virus travelled as a Word document — and that document, like all Word documents of its era, carried a GUID. Security researchers matched it to identifiers in the author's earlier postings, and within a week investigators had arrested David L. Smith, who was sentenced to 20 months in federal prison.
An identifier designed to make sure two computers never accidentally said the same thing had, in effect, become a fingerprint. The lesson stuck: modern systems almost never use MAC-based UUIDs, and the standard itself now recommends random node IDs. Version 1 solved uniqueness by being traceable — and its successor solved traceability by trusting something far stranger: luck.
Version 4: replacing memory with dice
The now-dominant version 4 UUID throws away the timestamp, the MAC address, and every other clever ingredient. After the six bookkeeping bits, the remaining 122 bits are pure randomness.
That sounds reckless. It is actually the most conservative bet in software, because 2¹²² is not a big number in the everyday sense — it is a number that breaks everyday intuition:
2¹²² ≈ 5.3 × 10³⁶ — about 5.3 undecillion possible UUIDs. If every human alive generated one million UUIDs per second, it would take over 20 billion years to run through them all.
But "we won't run out" isn't the interesting question. The interesting question is collision: what are the odds two independently generated UUIDs ever match? This is the birthday paradox — the same math that says a room of 23 people probably contains a shared birthday — and it cuts the safety margin dramatically, from 2¹²² down to roughly its square root.
Dramatically, but not fatally. To reach even a 50% chance of a single collision, you would need to generate about 2.7 × 10¹⁸ UUIDs — one billion per second, every second, for about 86 years. For a coin-flip's chance of one duplicate. Practical systems live so far below that threshold that engineers treat v4 collisions the way physicists treat all the air in a room spontaneously gathering in one corner: possible in principle, ignored in practice.
There is one real footnote to the fearlessness: the dice must be honest. UUIDs generated with a weak or badly seeded random source have collided in the wild. That's why proper generators — including the crypto.randomUUID() built into your browser — draw from a cryptographically secure source.
A field guide to the versions
Eight versions exist today. Most you will never meet.
| Version | Built from | Where you'll see it |
|---|---|---|
| v1 | Timestamp (since 1582) + MAC address | Legacy systems, older databases |
| v2 | v1 modified for DCE security | Almost nowhere — rarely implemented |
| v3 | MD5 hash of a name + namespace | Deterministic IDs from names |
| v4 | 122 random bits | Everywhere — the default choice |
| v5 | SHA-1 hash of a name + namespace | Like v3, with a stronger hash |
| v6 | v1 with the timestamp bits reordered | Migrating old v1 data |
| v7 | Unix timestamp (ms) + random bits | New databases — the rising star |
| v8 | Anything you like | Custom and experimental schemes |
Versions 3 and 5 are the quiet oddballs: they are deterministic. Hash the name example.com in the DNS namespace and you get the same UUID every time, on any machine, forever — uniqueness derived from the name itself rather than from time or chance.
2024: time makes a comeback
For twenty years, v4 randomness looked like the end of the story. Then databases pushed back.
A database index — a B-tree — loves ordered keys, where new entries land together at the "recent" end in warm memory pages. Random v4 keys land everywhere: every insert hits a random page of the index, causing page splits, cache misses, and write amplification. At scale, pure randomness turns out to be an expensive aesthetic.
So in May 2024, RFC 9562 — the first full revision of the standard in nineteen years — introduced version 7: a 48-bit Unix millisecond timestamp up front, randomness behind. UUIDv7s sort by creation time, so B-trees stay happy, while the random tail keeps them unguessable enough for identifiers. It is, in a sense, version 1's original idea — time plus something unique — rebuilt without the privacy leak, four decades of hindsight later. The timestamp up front also means every v7 UUID openly carries its own birth certificate: decode the first 48 bits and you know the millisecond it was made.
The same RFC canonized the standard's two ceremonial extremes: the Nil UUID (00000000-0000-0000-0000-000000000000) and the Max UUID (ffffffff-ffff-ffff-ffff-ffffffffffff) — the only two UUIDs that are famous precisely because no one should ever generate them.
The quiet miracle
The next time a UUID scrolls past in a log file, consider what it took to get there: a workstation company that no longer exists, a calendar decree from a sixteenth-century pope, a federal case that ended MAC-based identifiers, and the birthday paradox held at bay by 122 honest coin flips.
All so that two computers that have never met can name things — millions of times a second, everywhere on Earth — and never, ever disagree.
Generate your own UUIDsGenerate cryptographically random UUID v4 identifiers, one or in bulk, with uppercase, no-hyphen, and quoted formats.