UUID Generator

A UUID is 128 bits written as 36 characters, and the version digit tells you how those bits were chosen. Version 4 is 122 random bits and is the default for almost everything - it needs no coordination, leaks nothing about where it was made, and collisions are not a practical concern. Version 7, standardised in RFC 9562 in 2024, puts a 48-bit Unix millisecond timestamp in the high bits followed by randomness, so identifiers sort chronologically while remaining unguessable.

That sortability is the reason v7 exists and it matters more than it sounds. Database indexes on random keys suffer because every insert lands at a random point in the B-tree, scattering writes across pages and fragmenting the index. Time-ordered keys append at the end, keeping inserts sequential and the index compact. On a high-write table the difference is substantial, which is why v7 has quickly become the recommendation for new primary keys.

Versions 1 and 6 are also time-based but include the machine's MAC address, which leaks hardware identity - a real privacy consideration and the reason v1 fell out of favour. Versions 3 and 5 are deterministic: they hash a namespace and a name, so the same input always yields the same UUID. That is useful for deriving stable identifiers from existing keys, with v5 preferred since it uses SHA-1 rather than MD5.

Version 4 has 122 random bits, giving about 5.3 × 10^36 possible values. The birthday bound says you would need to generate roughly 2.7 × 10^18 UUIDs before reaching a 50% chance of a single collision. At a billion per second, that is around 85 years.

For a sense of scale at realistic volumes: generating a billion v4 UUIDs gives a collision probability of about one in 10^19. You are far more likely to lose the data to simultaneous hardware failure than to a duplicate identifier.

The important caveat is that this holds only with a cryptographically secure random source. `Math.random()` is not one - it is seeded from limited entropy and its output is predictable, so UUIDs built on it can both collide and be guessed. Browsers expose `crypto.getRandomValues()` and `crypto.randomUUID()` for exactly this reason, and any generator worth using calls one of them.

The advantages are real. A client can generate an identifier before talking to the server, so optimistic UI updates and offline-first workflows work without round trips. Merging data from several systems cannot collide. And because the keys are not sequential, they do not leak how many records you have or let anyone enumerate them - a sequential `/orders/1234` invites someone to try `1235`.

The costs are equally real. A UUID stored as text takes 36 bytes against 4 or 8 for an integer, and that cost is paid in every index and every foreign key. Storing it as a native 16-byte binary type - `uuid` in PostgreSQL, `BINARY(16)` in MySQL - recovers most of that. Random v4 keys also fragment indexes, which is the problem v7 was designed to solve.

The practical recommendation for a new system is v7 in a native UUID column: you get the coordination-free generation and non-enumerability of a UUID, with insert behaviour close to a sequential key.