UUID v1 vs v4

You need a unique identifier and your language offers at least two kinds of UUID. Version 1 and version 4 look almost identical, both 128 bits written as the same 36 character string, but they are built from completely different ingredients. Picking the wrong one can leak information you did not mean to publish.

What goes into a v1 UUID

A version 1 UUID is generated from a timestamp and a node identifier. The timestamp counts 100 nanosecond intervals since October 1582, and the node field is traditionally the machine's MAC address. A clock sequence guards against the clock moving backward.

Because the timestamp sits in a known position, two useful and two uncomfortable properties follow. The useful ones: IDs generated close together are roughly ordered, and you can extract the creation time. The uncomfortable ones: the MAC address identifies the machine that created the ID, and the embedded time can reveal when a record was made. Handing a v1 UUID to an external party can disclose more than you intended.

What goes into a v4 UUID

A version 4 UUID is almost entirely random. Of the 128 bits, 6 are fixed to mark the version and variant, leaving 122 random bits. There is no timestamp, no machine identity, and no ordering. One v4 UUID tells an observer nothing except that it is a v4 UUID.

v1: 2f1a8c9e-5b3d-11ee-8c99-0242ac120002  (time + node)
v4: 9b2e4f7a-6c1d-4e88-a3f5-1d9c8b7e2a04  (random)

The version digit is the first character of the third group. A 1 there means v1, a 4 means v4.

Collision odds

Randomness raises the obvious worry: can two v4 UUIDs collide? With 122 random bits the space is about 5.3 times 10 to the 36th. By the birthday bound you would need to generate on the order of a billion UUIDs per second for about 85 years before a collision became likely. For any normal application the risk is not worth modeling. The deeper math is covered in are UUIDs really unique.

Which to pick today

For most new work, reach for v4. It leaks nothing and needs no coordination between machines. The one thing it lacks is ordering, which hurts database index locality because random inserts scatter across the index.

If you want both randomness and sortability, the modern answer is v7, which places a Unix millisecond timestamp in the high bits and fills the rest with random data. You get time ordering without exposing a MAC address. Reserve v1 for legacy systems that already depend on it.

You can generate any of these in the UUID & Token Generator, which runs client side so no identifier is ever sent to a server. If you are weighing shorter alternatives, see nanoid vs uuid.

The practical takeaway: default to v4 for safety, move to v7 when you need database friendly ordering, and avoid v1 unless an existing system forces it.