UUID generator: v1, v3, v4, v5, v7 and ULID explained

A UUID (Universally Unique Identifier) is a 128-bit value. Its purpose: independent systems can mint IDs without coordinating and still avoid collisions in practice - no central sequence service, no shared registry. The various versions mix timestamp, randomness, and (historically) hardware bytes differently. The right choice depends on whether the ID needs to be sortable, deterministic, or just random. The generator below shows the layout per version live: which bytes are reserved for a timestamp, which for randomness, which for a node field - and which properties fall out of those choices. v7 next to v4 - the sortability demo at the bottom shows in two clicks why v7 wins in databases.

Which UUID version do you actually need?

Three questions usually decide it:

1. Do you need sortability? If the ID will be a database primary key, an event ID, or a URL-safe time axis - pick v7 (RFC 9562) or ULID. Both place a millisecond timestamp at the front, so a string sort matches insertion order down to the millisecond (within the same ms, the implementation's counter or random tail decides the rest).
2. Do you need determinism? If the same input must always yield the same ID, pick v3 (MD5) or v5 (SHA-1). v5 is the cleaner choice.
3. Otherwise: v4. Pure randomness from the browser's crypto APIs, no state, no device leak.

You almost never need v1 - unless a legacy system demands it. The last 6 bytes of a v1 UUID are a 48-bit node field; depending on the implementation, that's the host's MAC address. The library this generator uses draws random node values, but plenty of other v1 generators still embed the real MAC. Anyone forwarding v1 IDs from logs or foreign APIs should treat those last 6 bytes as potentially sensitive.

The 128-bit layout per version

Every card above shows the layout in coloured bands. The notable differences:

• v1 - time + node. Three timestamp runs (time_low, time_mid, time_hi), permuted. A clock_seq field protects against clock jumps. The last 6 bytes are the 48-bit node field - historically a MAC address, randomly generated here.
• v3 / v5 - hash. The output is the MD5 or SHA-1 hash of namespace + name. Version and variant bits are written into the hash; everything else is hash bytes.
• v4 - random. 122 bits of cryptographic random. 4 bits version, 2 bits variant - that's it.
• v7 - time + random. 48-bit ms timestamp at the front, then 74 bits for random data and/or a monotonic counter (RFC 9562 leaves the precise split open). Version and variant bits separate the two regions.
• ULID - Crockford-32. 48-bit ms timestamp + 80-bit random, rendered in 26 Crockford-base32 characters. No 0/O or I/L ambiguity.

v4 or v7 - the sortability demo

The demo below draws 10 v4s and 10 v7s in shuffled order. Click "Sort alphabetically" - the left column (v4) lands at random positions, the right column (v7) sorts back into generation order. That's exactly what happens in a database when you use a UUID column as a primary and sort key:

• With v4, every new row inserts at a random position in the B-tree index. Pages fragment; I/O scatters.
• With v7, new rows almost always sit at the end of the sorted sequence. Index pages stay tight; I/O stays sequential.

In MySQL and Postgres benchmarks over the last few years, the difference on large tables is often a single-digit factor in v7's favour. ULID has the same behaviour - just in a different notation.

When are v3 and v5 the right choice?

When the ID should be derived from something stable: a URL, a DNS name, a path, a file's content. Same input → same ID, without ever asking a database.

v5(DNS namespace, "example.com") = cfbff0d1-9375-5685-968c-48ce8b15ae17
v5(DNS namespace, "example.com") = cfbff0d1-9375-5685-968c-48ce8b15ae17

The namespace itself is a UUID. RFC 9562 Section 6.6 (Table 3) defines four standard namespaces - DNS, URL, OID, X.500 - which the generator above offers as presets. You can also use your own UUID as a namespace, e.g. one per application, so the same name yields different IDs across applications.

Prefer v5 over v3 because SHA-1 is a more robust hash than MD5 - though no cryptographic security is at stake here; it's only about good bit distribution.

What about v6, v8 and Microsoft GUIDs?

• v6 is v1 with the timestamp bytes reordered - sortable like v7. Its node field carries the same MAC question as v1: depending on the implementation, it can contain the real address or a random value. Barely deployed; v7 wins in practice.
• v8 is RFC 9562's "custom" slot for proprietary layouts. If you need it, you know; if you don't, you don't.
• Microsoft GUIDs are UUIDs in a big-endian / little-endian mix. When passing IDs between .NET and the rest of the world, watch for swapped bytes in the first three fields.

Bulk generation: 1, 10, 100, 1000

The "How many?" switch above draws the chosen count in one go. The list copies as a JavaScript array, CSV, or JSON - handy for seed data, load tests, or just observing how the layout behaves over many entries. With v7 the leading ms timestamp advances by one millisecond per row (so the demo has a visible sortability trace); with v4 you can see the uniform distribution of the random.

FAQ

Which UUID version should I use?

Default to v4 for session IDs and anything not needing order. v7 for database primary keys and event IDs - the timestamp prefix makes v7 sortable. v3 / v5 only for deterministic IDs from names (prefer v5 over v3). v1 only in legacy systems - the node field can carry the MAC depending on the stack.

What is UUID v7 and why is it sortable?

v7 (RFC 9562, 2024) has a 48-bit ms timestamp at the front, followed by 74 bits for random data and/or a monotonic counter (split across the version and variant bits). Because the timestamp occupies the leading bytes, v7 UUIDs sort lexicographically by millisecond time; ordering within the same millisecond depends on the implementation.

Does a v1 UUID leak my MAC address?

It depends. The last 6 bytes are a 48-bit node field - historically the MAC, but commonly random depending on the implementation. If you forward UUIDs from unknown stacks, prefer v4 or v7.

What's the difference between UUID and ULID?

ULID is a popular non-RFC scheme: 26 Crockford-base32 characters, 48-bit ms timestamp + 80-bit random. Sortable like v7, URL-friendlier, and unambiguous about 0/O and I/L.