UUID Generator (v4 and v7)

A UUID is a 128-bit identifier that any computer can create on its own, with no central registry, and still be practically certain nobody else will ever create the same one. The format is defined by RFC 9562, which replaced the older RFC 4122 in May 2024. Microsoft calls the same thing a GUID.

It is written as 32 hexadecimal digits in five groups, 8-4-4-4-12. Two digits carry metadata:

• The 13th digit is the version: the 7 in 017f22e2-79b0-7cc3-… means version 7.
• The 17th digit holds the variant. For standard UUIDs its top two bits are 10, so it is always 8, 9, a or b.

The version says how the other bits were made:

Version 2 (DCE Security) exists but is almost never used.

RFC 9562 also defines two special values: the nil UUID (all zeros), meaning "no value", and the max UUID (all f), a sentinel for things like range bounds. Paste either into the inspector above to see them recognized.

Both are 128 bits and both are safe to generate anywhere. The difference is what fills the bits.

Use v7 for database primary keys and anything you sort or paginate by. Random v4 keys land on random pages of a B-tree index, so a large table suffers page splits and poor cache locality on every insert; v7 keys arrive in roughly ascending order, so new rows go to the same "hot" pages, much like a sequential integer key.

Use v4 when the ID is public and its creation time should stay private, for example a share link or an external reference. Anyone can read a v7's timestamp; paste one into the inspector to see it.

A millisecond is a long time for a computer: this page can make a thousand v7 UUIDs inside one. If the bits after the timestamp were purely random, UUIDs from the same millisecond would sort in a random order.

RFC 9562 §6.2 describes several fixes. This generator uses method 1, a dedicated counter: the 12 bits after the version digit (rand_a) start at a random value with the top bit clear, and each UUID created in the same millisecond adds one. The rest stays random. Two edge cases are handled the way the RFC allows:

• If the counter would overflow, the timestamp is advanced by one millisecond.
• If the system clock jumps backwards, the last timestamp is reused, so the sequence never goes down.

Monotonic ordering is guaranteed per generator. UUIDs made on different machines in the same millisecond interleave in random order, which is still close enough to time order for indexes.

In theory yes, in practice no. A v4 UUID has 2^122 possible values (about 5.3 × 10^36). By the birthday bound, you would need roughly 2.7 quintillion (2.7 × 10^18) v4 UUIDs before the chance of even one duplicate reaches 50%.

Real-world duplicates come from broken randomness, not from the math: a Math.random() polyfill, two virtual machines restored from the same snapshot, or a forked process that copies its parent's generator state. Browsers' crypto.randomUUID() and crypto.getRandomValues(), which this tool uses, are cryptographically secure. To estimate risk for shorter IDs, try the collision calculator in the nanoid generator.

Store the 16 bytes, not the 36-character string. A native type is smaller, faster to compare and validates input for free:

• PostgreSQL: the uuid type (16 bytes). gen_random_uuid() makes v4; PostgreSQL 18 adds uuidv7().
• SQL Server: uniqueidentifier. Note that it sorts by the last group first, so v7 values do not sort by time there.
• MySQL: BINARY(16) with UUID_TO_BIN() and BIN_TO_UUID().

In .NET, Guid.ToByteArray() writes the first three groups little-endian. When exchanging raw bytes with other systems, use ToByteArray(bigEndian: true) (.NET 8 and later).

Most platforms have v4 built in, and v7 support is arriving quickly:

// JavaScript (browsers and Node.js 19+)
crypto.randomUUID();                // v4

# Python
import uuid
uuid.uuid4()                        # v4
uuid.uuid7()                        # v7, Python 3.14+

// Go — github.com/google/uuid
uuid.New()                          // v4
uuid.NewV7()                        // v7, returns (UUID, error)

// C# (.NET 9+)
Guid.NewGuid();                     // v4
Guid.CreateVersion7();              // v7

-- PostgreSQL
SELECT gen_random_uuid();           -- v4
SELECT uuidv7();                    -- v7, PostgreSQL 18+

Generating the ID in your application rather than the database lets you know it before the insert, which simplifies creating related rows and retrying requests safely.