About the UUID generator

What this tool does

This generator mints universally-unique 128-bit identifiers in two of the eight formats defined by RFC 9562^[1]: UUID version 4 (fully random) and UUID version 7 (a 48-bit Unix-millisecond timestamp followed by 74 bits of random data). It does so entirely inside your browser, using the Web Crypto API's cryptographic random-number generator, with no network calls on any path. You can mint a single value, or up to one hundred at a time, and prepend an optional short prefix like user_ so the IDs are self-describing in logs. The tool does not parse, decode, or validate UUIDs — it only generates them. It does not produce v1, v3, v5, v6, or v8 (those are out of scope for the v1 release), and it does not let you supply a custom v7 timestamp seed.

What a UUID is

A UUID is 128 bits — sixteen bytes — laid out as a canonical 8-4-4-4-12 lowercase hex string with hyphens. The format is xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the version nibble (the top four bits of byte 6) and the top two bits of N are the variant bits (always 10 for the RFC 4122/9562 variant, meaning the first hex character of the fourth group is 8, 9, a, or b). The word “universally unique” is a probability statement, not a guarantee — a v4 has 122 bits of entropy, so the standard birthday-bound says you would have to mint on the order of 2⁶¹ (≈ 10¹⁸) of them before there's a fifty-percent chance of one collision. For any realistic application that's a guarantee in the operational sense, but the math is what underwrites it.

Brief history

UUIDs began as Apollo Computer's Network Computing System (NCS) UIDs in the mid-1980s, where each ID combined a host MAC address with a 48-bit timestamp so machines on a LAN could co-ordinate without a central allocator. The Open Software Foundation absorbed the design into its Distributed Computing Environment (DCE), which Microsoft then carried into COM, where the format became known as a GUID. ISO/IEC standardised it in 11578:1996, and the IETF formalised it for the public internet in RFC 4122^[2] (Leach, Mealling, Salz; July 2005), which specified versions 1, 3, 4, and 5 and was the canonical reference for the next two decades. RFC 4122 was obsoleted in May 2024 by RFC 9562^[1] (Davis, Peabody, Leach), which inherits v1–v5 unchanged and adds v6, v7, and v8. The v7 addition is the IETF formally blessing what production systems had been hand-rolling for a decade — ULID, KSUID, Snowflake, and similar schemes had all converged on the same design: put a timestamp in the high bits so the IDs sort in creation order, then fill the rest with random bytes for uniqueness. Anyone who has had a database index thrash under load knows why that ordering matters.

UUID v4 — the bit layout

A v4 UUID is straightforward: 122 random bits, plus a four-bit version field set to 0100 (the binary for 4), plus the two-bit 10 variant. The version nibble lives in the top four bits of byte 6, which means the thirteenth hex character of any v4 is the literal 4. The variant bits live in the top two bits of byte 8, which means the seventeenth hex character is one of 8, 9, a, or b. Modern browsers expose crypto.randomUUID() which mints a v4 directly from the platform CSPRNG with no library required, and that is what this tool uses on the v4 path. The collision argument is the birthday-bound on 122 bits of entropy — at one billion mints per second, a fifty-percent collision chance arrives after roughly seventy years. The v4 is the right answer when you need an opaque identifier whose value must not leak any information about when, where, or by whom it was minted.

UUID v7 — the bit layout

A v7 UUID is laid out as a 48-bit big-endian Unix-millisecond timestamp, the four-bit version field set to 0111, twelve bits of random data called rand_a, the two-bit variant 10, and a final sixty-two bits of random data called rand_b — seventy-four random bits in total. The timestamp sits in the high bits specifically so that lexicographic order over the textual form equals chronological order. The version nibble appears as the literal 7 at the thirteenth hex character, and the variant nibble appears at the seventeenth position with the same 8/9/a/b constraint as v4.

The B-tree-locality argument is the practical reason most teams now reach for v7 over v4 when the UUID is a primary key. Random v4 keys insert into a B-tree at uniformly distributed positions, so every insert dirties a different page; the buffer pool fills with hot pages that are written once and then never touched again. A v7 key inserts at the rightmost edge of the tree, co-locating recent inserts on the same page, so the hot working set stays small and the write amplification stays low. The same property makes range scans by creation time effectively free. The cost is that a v7 leaks the moment of creation to anyone who sees the ID; that is acceptable for internal identifiers and database primary keys, and it is a problem for anonymous tokens exposed to the public, where you should prefer v4.

The 74 bits of entropy after the timestamp are plenty: even at a theoretical one-million-IDs-per-millisecond rate, the birthday-bound on rand_a + rand_b sits far above the collision floor. This tool implements v7 directly per RFC 9562 §5.7 in roughly twenty lines: read 48 bits from Date.now(), pull ten random bytes from crypto.getRandomValues, and mask in the version and variant nibbles before formatting.

The other versions, briefly

v1 mixes a 60-bit timestamp with the host MAC address; useful when you need cluster-wide monotonicity, problematic when you ship IDs across an organisational boundary because the MAC leaks. v3 is the MD5 hash of a name inside a namespace, producing deterministic IDs (same input, same output) — handy for derived keys. v5 is the SHA-1 variant of v3 and is preferred over v3 when you have the choice. v6 is a re-ordered v1 that sorts lexicographically; it has been almost entirely superseded by v7. v8 is the custom escape hatch — RFC 9562 explicitly allows you to encode bits any way you like, as long as you flag the result as v8 with the variant bits intact.

How to choose between v4 and v7

A short decision table for the two versions this tool emits:

• Opaque public identifier — an anonymous share link, an unguessable cancel-token, an email-unsubscribe URL — pick v4. You do not want the value to leak its creation time, and you do not need ordering.
• Database primary key for a table you also want to query in time order — pick v7. The B-tree pays you back immediately, and the timestamp leak is internal-only.
• Log correlation or trace ID that needs to sort by recency — pick v7. The timestamp is the whole point.
• One-shot idempotency key on a POST or a retry — pick v4. Ordering does not matter; opacity is the safer default.

Common use cases

Database primary keys (v7 increasingly preferred over v4 for this), idempotency keys on HTTP POSTs, correlation IDs across a distributed trace, upload filenames where you need an unguessable name, event IDs in an event-sourced system, job IDs in a worker queue, and the jti claim of a JWT you mint server-side. The bulk mode in this tool is for the moments you need a fistful at once: seeding fixtures for a test database, populating a CSV column for an import, scripting an ad-hoc batch of idempotency keys for a one-off migration.

Pitfalls

The cluster of mistakes that recurs across every team:

• Truncating a UUID. Collision probability climbs nonlinearly with each lost bit. A 64-bit-truncated UUID is a 64-bit identifier; treat it as one.
• Treating UUID uniqueness as security. A v7 leaks creation time, and a v4's 122 random bits are only as strong as the CSPRNG behind them. For a cryptographically unguessable token, use crypto.getRandomValues(new Uint8Array(32)) and base64-url-encode the result.
• Generating with Math.random. Math.random is not a CSPRNG. RFC 9562 §6.9 requires a cryptographic source; this tool uses crypto.randomUUID and crypto.getRandomValues for that reason.
• Using v1 across an organisational boundary. The MAC address is part of the identifier. Don't.
• Forgetting that v7 reveals approximately when it was minted. Fine for internal IDs, occasionally a problem for public ones.

References

1. Davis, K., Peabody, B., & Leach, P. (2024). RFC 9562 — Universally Unique IDentifiers (UUIDs). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc9562.html — canonical bit layouts for v1–v8 including §5.4 (v4) and §5.7 (v7), the 8-4-4-4-12 textual form (§4), and the §6.9 requirement that random bits come from a CSPRNG.
2. Leach, P., Mealling, M., & Salz, R. (2005). RFC 4122 — A Universally Unique IDentifier (UUID) URN Namespace. Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc4122.html — the original UUID specification, now obsoleted by RFC 9562 but still the version most existing code in the wild was written against; cited for historical context and the v4 algorithm RFC 9562 inherits verbatim.