UUID Batch Generator

What this works out

A version 4 UUID is a 128-bit identifier whose payload is random except for six bits that say what layout it uses. It does not contain a timestamp, a machine address or a database counter. That is why independent systems can generate values without coordinating a central service.

This tool makes a batch rather than one decorative string. Every generated UUID is a table row, so the result can be copied, inspected for a duplicate, or downloaded as CSV and used as seed data, fixture identifiers or import keys.

The method

RFC 9562 permits an implementation to draw all 128 bits first, then replace the version and variant fields. Written as zero-indexed octets:

octet 6 = (random octet 6 AND 00001111) OR 01000000
octet 8 = (random octet 8 AND 00111111) OR 10000000

The first expression forces the high nibble of octet 6 to hexadecimal 4. The second forces the two most-significant bits of octet 8 to binary 10, so its first hexadecimal digit is 8, 9, a or b. All other bits and the low bits preserved by those masks remain random: 122 bits in total.

Web Crypto limits one getRandomValues request to 65,536 bytes. A maximum batch contains 160,000 bytes, so the implementation fills the allocation in bounded chunks instead of relying on a request the platform must reject.

Before you read on

Which canonical string has both the version 4 and RFC variant fields in the right positions?

• A00000000-0000-3000-8000-000000000000

  The variant is right, but the first nibble of the third group says version 3.

• B00000000-0000-4000-7000-000000000000

  The version is right, but 7 begins with variant bits 01 rather than 10.

• C00000000-0000-4000-a000-000000000000

  Yes. The third group starts with 4 and a starts with binary 10.

00000000-0000-4000-a000-000000000000. Version 4 occupies the first nibble of the third group; the RFC variant is visible as 8, 9, a or b at the start of the fourth.

A worked bit-layout example

Tests need a repeatable byte source even though the live generator must not. Feeding the authored algorithm the 16 bytes 00 01 02 ... 0f gives:

random:  00010203-0405-0607-0809-0a0b0c0d0e0f
UUIDv4:  00010203-0405-4607-8809-0a0b0c0d0e0f
                         ^    ^
                      version variant

Only the required high bits of octets 6 and 8 changed. The formula test asserts that complete vector, then uses the real Web Crypto source for 100 UUIDs and checks every value against the version/variant grammar. Another test generates the full 10,000-row limit and proves no random request exceeds 65,536 bytes.

Canonical, compact and URN forms

The familiar representation groups 32 hexadecimal digits as 8-4-4-4-12:

00010203-0405-4607-8809-0a0b0c0d0e0f

Compact text removes the four hyphens. URN text prefixes the canonical value:

urn:uuid:00010203-0405-4607-8809-0a0b0c0d0e0f

Uppercase changes a through f to A through F. None of these operations changes a bit in the UUID; they are formatting contracts for the system that will consume the list.

Collision probability, stated honestly

There are 2^122 possible random payloads. For n uniformly generated UUIDs, the birthday approximation for at least one collision is:

p ≈ n × (n - 1) / (2 × 2^122)

For 10,000 values that is roughly 9.4 × 10^-30. Tiny is not zero, and a cryptographic generator is still an implementation dependency. The table’s duplicate counter catches a repeat inside this batch, while a database unique constraint remains the right final authority across every batch and system.

What it does not do

It does not generate time-ordered UUIDv7 values, deterministic name-based UUIDv5 values, or database-specific binary encodings. It also does not promise that a UUID is secret, signed or resistant to modification. Its one job is a standards-shaped batch of cryptographically random version 4 identifiers.