# UUID generator

URL: https://www.toolflux.app/en/uuid-generator/
Stand: 2026-05-02

UUID generator with a per-version layout diagram: v1, v3, v4, v5, v7 and ULID. v7 is sortable, v4 is random, v3/v5 are deterministic. All in your browser.

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.

| Version | Random bits | Sortable | Privacy concern | Status |
|---|---|---|---|---|
| v1 | ~61 (node + seq, random here) | half | node field may be MAC | Legacy |
| v3 | 0 (deterministic) | no | MD5 is old but stable | Legacy |
| v4 | 122 | no | none | Current |
| v5 | 0 (deterministic) | no | none | Current |
| v7 | 74 (random/counter) | yes | timestamp readable | Modern |
| ULID | 80 | yes | timestamp readable | Modern |

## 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.

### FAQ

**Which UUID version should I use?**

Default to v4 (random) for session IDs or anything that doesn't need order, or v7 (RFC 9562) for database primary keys and event IDs - the timestamp prefix makes v7 sortable both as a string and as a binary key. Use v3 or v5 only when you need deterministic IDs derived from names. Use v1 only in legacy systems - the 48-bit node field can carry the host MAC depending on the implementation.

**What is UUID v7 and why is it sortable?**

v7 was standardised in RFC 9562 (2024). Layout: 48-bit ms timestamp at the front, then 74 bits for random data and/or a monotonic counter (RFC 9562 leaves the split open), plus version and variant bits between them. Because the timestamp occupies the leading bytes, v7 UUIDs sort lexicographically by their millisecond prefix; within the same millisecond, ordering depends on whether the implementation runs a monotonic counter or pure random in the remaining bits. In databases that means much less index fragmentation than with v4.

**Does a v1 UUID leak my MAC address?**

It depends on the implementation. v1 reserves the last 6 bytes for a 48-bit node field - historically the generating host's MAC. RFC 9562 also permits random node values, and the library behind this generator (the `uuid` package) draws random ones. Other v1 generators do still embed the real MAC. If you forward v1 UUIDs from foreign stacks, treat the last 6 bytes as potentially sensitive.

**What's the difference between UUID and ULID?**

ULID is not an RFC. It's Alizain Feerasta's popular scheme: 26 Crockford-base32 characters (vs 36 in UUID notation), 48-bit ms timestamp + 80-bit random. Lexicographically sortable like v7 but more URL-friendly and unambiguous (no 0/O or I/L confusion). If you don't strictly need RFC compliance and want shorter IDs, ULID is the pragmatic choice.

**How deterministic are v3 and v5?**

Fully: the same input (namespace + name) always returns the same UUID. v3 uses MD5, v5 uses SHA-1 - neither is reversible to the name, but neither is a cryptographic secret. For stable IDs from URLs, paths, or slugs, v5 is the better choice because SHA-1 is preferable to MD5.

**How do I generate 1000 UUIDs at once?**

Set 'How many?' to 1000 in the generator above. The list can be copied as a JavaScript array, CSV, or JSON. v4 draws a fresh 122-bit random from the browser's crypto APIs for each UUID; v7 keeps order, with the timestamp advancing by one millisecond per row. This generator's ULID implementation is monotonic within the same millisecond (it increments the random tail); the canonical ULID spec only requires that for explicitly monotonic generators.

**Which UUID version sorts by generation time?**

v7 and ULID. v1 is half-sortable - it has a timestamp, but RFC 4122 permutes the bytes (time_low, time_mid, time_hi), so a string or binary sort doesn't follow generation order. v4, v3, and v5 are not sortable; v3 and v5 are deterministic, so they're independent of generation time entirely.