UUID Generator — v4 random & v7 time-ordered

A UUID is a 128-bit value rendered as 32 hexadecimal digits in the canonical 8-4-4-4-12 form. Four bits encode the version and two bits encode the variant; the remaining 122 bits carry the payload. This tool implements the two versions most useful in practice — UUIDv4 and UUIDv7 — exactly as specified in RFC 9562 (May 2024, obsoletes RFC 4122).

1. Random bytes. The browser draws 16 bytes from window.crypto.getRandomValues — the cryptographically secure pseudo-random source the browser uses for TLS, WebCrypto, and Subresource Integrity. No fallback to Math.random is ever used. This is the same primitive Node's crypto.randomUUID() uses internally.
2. UUIDv4 (§5.4). All 16 bytes start as random. Byte 6 is then masked to set the version nibble: byte6 = (byte6 & 0x0F) | 0x40. Byte 8 is masked for the variant: byte8 = (byte8 & 0x3F) | 0x80. The result is 122 bits of entropy with a recognisable layout: the third group always starts with 4 and the fourth group starts with 8, 9, a, or b.
3. UUIDv7 (§5.7). Bytes 0–5 store the 48-bit Unix timestamp in milliseconds, big-endian. Byte 6 carries the version nibble (0111) in its high four bits and 4 random bits in its low four bits. Byte 7 is 8 more random bits — those 12 random bits together are rand_a. Byte 8 carries the variant (10) in its high two bits, followed by 62 random bits across bytes 8–15 (rand_b). The time prefix means v7 values are lexicographically sortable in generation order — a property B-tree indexes love.
4. Bulk mode. For batches, the v4 path simply calls the v4 generator n times. The v7 path increments the timestamp by 1 millisecond per record so the batch sorts strictly in generation order even if many UUIDs land on the same millisecond boundary; the 74 random bits keep each record globally unique.
5. Verification.Every render runs a self-test: known input bytes → expected canonical UUID, then v7 timestamp write → independent read-back, then a structural verifier that checks length, hyphen positions, hex-only characters, version nibble, and variant bits via a separate code path from the generator. The “RFC 9562 verified” badge in the card header lights up only when all four cross-checks pass.

The output format chips are reversible cosmetic transforms applied after generation: case is RFC-canonical lowercase by default, but UPPER, no-hyphens (32-char compact), Microsoft-style {braces}, and the RFC 4122 §3 urn:uuid: prefix are one click away. Copying preserves the chosen format; so do the .txt and .csv downloads. The CSV export includes a per-record ISO-8601 timestamp column for v7 batches so the file is analysis-ready in any spreadsheet.

Collision analysis: by the birthday-paradox approximation, drawing n ≈ √(2 · 2¹²² · ln(1/(1-p))) UUIDv4 values gives a probability p of any pair colliding. For p = 0.5 that is ≈ 2.71 × 10¹⁸ values — one billion UUIDs per second for 85 years from a single source. Within any realistic application, collisions are not a meaningful failure mode.

• RFC 9562 — Universally Unique IDentifiers (UUIDs), May 2024
• RFC 4122 — A UUID URN Namespace (obsoleted by RFC 9562)
• W3C Web Crypto API — Crypto.getRandomValues() (CSPRNG source)
• IETF UUID Revision (uuidrev) — working group history
• PostgreSQL — UUID Type documentation

The bit layouts and verification routines on this page were last cross-checked against RFC 9562 on 2026-05-11. The spec is stable; if the IETF UUID working group publishes a clarification, the tool is reviewed and updated.