UUID v1, v4 and v7: which identifier should you actually use?

A UUID is 128 bits, conventionally written as 36 characters with four hyphens. Its promise is uniqueness without coordination: any machine can mint one at any time without asking a central authority, and the probability of a clash stays negligible. That property is what makes UUIDs the default identifier for distributed systems, offline-first clients and merge-heavy data pipelines.

Six bits are reserved for version and variant, so the practical randomness of a v4 UUID is 122 bits. At that size you would need to generate billions of identifiers per second for decades before a collision became likely — this is not the risk you should be worrying about.

Nine versions exist on paper; three appear in real codebases.

• v1 — timestamp plus node identifier. Sortable-ish, but historically leaked the MAC address of the generating machine.
• v4 — random. Simple, private, unpredictable, and the correct default when you have no other requirement.
• v7 — a millisecond timestamp followed by randomness. Keeps v4's collision resistance while sorting in creation order, which makes it the modern choice for database primary keys.

A random v4 primary key lands in an arbitrary position in a B-tree index on every insert. On clustered-index engines such as InnoDB that means page splits, poor cache locality and fragmentation that grows with the table. The symptom is an insert path that quietly degrades as data volume rises — often blamed on the wrong thing entirely.

Time-ordered identifiers fix this because each new key appends near the right edge of the index. If you are choosing an identifier for a table that will grow large, prefer v7 (or an equivalent ordered id) as the storage key. If you already ship v4 keys, storing them as native 16-byte binary rather than a 36-character string still recovers a lot of space and index efficiency.

UUIDs are unguessable, which is useful, but they are not access control — a resource reachable by anyone holding the id is still unauthorised access waiting to happen. They are also poor user-facing identifiers: nobody reads a UUID over the phone, and they consume a lot of space in URLs and logs.

For public-facing references consider a short, high-entropy slug (Nano ID style) for readability, or a signed opaque token when the identifier must not be enumerable. Reserve UUIDs for internal, machine-to-machine identity where their coordination-free property is what you are actually buying.

Whatever version you pick, the randomness must come from a cryptographically secure source. In the browser that is crypto.getRandomValues, which backs crypto.randomUUID and every reputable library. Math.random is not a substitute — it is fast, seeded and predictable.

Our UUID generator runs on the browser's crypto API and supports bulk output for seeding fixtures and test data. Because it is client-side, the identifiers it produces are never transmitted anywhere, which matters when you are minting keys that will end up in a real system.