UUID v1 Generator

What is UUID v1?

UUID v1 combines a 60-bit timestamp (100-nanosecond intervals since 15 October 1582), a clock sequence, and a node identifier historically derived from the machine's MAC address. In browsers, a random node identifier is used instead, avoiding hardware fingerprinting.

Should I still use v1?

Only when integrating with legacy systems that expect v1. Its timestamp bytes are stored in an order that does not sort naturally, and embedding node identity raised privacy concerns. For new time-ordered IDs, UUID v7 is the modern replacement.

Does UUID v1 expose my MAC address?

It can, depending on where it is generated. The original specification fills the final 48 bits — the node field — with the machine's MAC address, which is why v1 values created by older server-side libraries can identify the exact network interface that produced them. RFC 9562 permits a random node identifier instead, and that is what modern implementations increasingly use. This generator runs entirely in your browser, which has no access to hardware addresses at all, so the node field here is filled with random bits and identifies nothing. If you generate v1 on a server with a library that still reads the interface, assume the address is embedded and treat those identifiers as internal rather than public.

Why does UUID v1 sort badly?

Because its timestamp is split across the value with the least significant part first. A v1 UUID stores the low 32 bits of the timestamp in the opening group, the middle 16 bits next, and the high 12 bits after that — so lexicographic order jumps around instead of following time. Two UUIDs created a second apart can sort far from each other, which is exactly the property that makes v1 a poor database primary key: inserts scatter across the index just like random v4 values. UUID v7 fixes this by putting a plain big-endian 48-bit Unix millisecond timestamp at the front, so string and byte ordering both match creation order.