UUID generator

Version 4 is a UUID made of random bits — 122 of them, with the remaining six fixed to declare the version and variant. It carries no information about when or where it was made, which is exactly why it is the default: nothing about it leaks, and two generated independently anywhere in the world will not clash.

The others answer different questions. Versions 1 and 6 embed a timestamp and a node identifier, so they sort by creation time and disclose something about the machine. Versions 3 and 5 are deterministic — a hash of a name inside a namespace, so the same name always yields the same UUID. Version 7 is the newer time-ordered one, designed for database keys where random insertion hurts an index.

A UUID from `Math.random` has the same shape, the same dashes and the same version nibble as one from a cryptographic source. Nothing about it looks weak. But `Math.random` is a fast pseudo-random generator with a small internal state, and a handful of outputs can be enough to predict the rest — which turns a "random" identifier into a guessable one.

This page uses `crypto.randomUUID`, which draws from the operating system entropy and sets the version and variant bits correctly. Where it is unavailable, the page stops and says so rather than falling back — a silent fallback is how predictable identifiers reach production, because there is no symptom to notice.

It is unguessable, which is not the same as secret. UUIDs end up in URLs, in logs, in referrer headers, in analytics, in support tickets and in screenshots. Anything reachable by knowing a UUID is reachable by anybody who has ever seen that URL.

That makes them fine as an unguessable handle for something not very sensitive — a share link for a document, a one-off upload — and wrong as the only thing standing between the internet and somebody data. If knowing the identifier grants access, you have built authentication out of a value that leaks by design.

There are 2^122 possible version 4 UUIDs. To reach a one-in-a-billion chance of a single collision you would need to generate around 10^15 of them — a billion a second for about a month. For any real system the answer is that it will not happen.

The caveat is that this holds only if the randomness is real. Every reported UUID collision in the wild traces back to a weak or badly seeded generator: containers starting from an identical image and seeding from the clock, an embedded device with no entropy at boot, a library that fell back to `Math.random`. The mathematics is not the risk; the source is.

A random UUID as a primary key spreads inserts uniformly across the index, which is the opposite of what a B-tree wants — every insert touches a different page, the cache stops helping, and the index fragments. On a large table that is a measurable and well-documented cost.

The usual answers are a time-ordered UUID such as version 7, or a separate sequential key with the UUID kept as an external identifier. It is worth deciding deliberately rather than discovering it at scale, because changing a primary key type later is among the more expensive migrations there is.