UUID Generator

What Is a UUID (or GUID)?

A UUID (universally unique identifier) is a 128-bit value that any system can create on its own, without asking a central server for the next number, and still be confident nobody else will create the same one. It is written as 32 hexadecimal digits in five groups, 8-4-4-4-12, for 36 characters in total:

017f22e2-79b0-7cc3-98c4-dc0c0c07398f

The first digit of the third group is the version (7 here), and the first digit of the fourth group holds the variant, which is 8, 9, a or b for standard UUIDs. That is why a v4 UUID always matches the pattern xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx.

The current standard is RFC 9562, published in May 2024. It replaces RFC 4122, keeps versions 1 to 5 as they were, and adds versions 6, 7 and 8 plus the Max UUID (all bits set to one).

UUID vs GUID: GUID is the name Microsoft uses for the same thing. Windows tools such as the registry tend to show GUIDs in uppercase with braces, like {3F2504E0-4F89-41D3-9A0C-0305E82C3301}, but the value underneath is a regular UUID. (.NET's Guid.ToString() prints lowercase without braces by default.) The one practical difference shows up in binary: Windows stores the first three groups little-endian, so raw 16-byte GUIDs can look scrambled when another system reads them.

UUID Versions Compared

The version tells you how the 128 bits were built. These six versions cover nearly every real use:

Which one to pick: use v7 for new database keys and v4 for opaque random IDs. Random v4 keys land at random positions in a B-tree index, which causes page splits and poor cache use as tables grow. A v7 key starts with the time, so new rows are appended near the end of the index and stay close to their neighbors. The trade-off is that anyone holding a v7 UUID can read when it was created.

Version 2 (DCE Security) is almost never used, and version 8 is a free-form layout for vendor-specific schemes. One database caveat: SQL Server sorts uniqueidentifier values starting from the last group, so v7 does not give you index locality there without extra work.

How Likely Is a UUID Collision?

Six of the 128 bits in a v4 UUID are fixed by the version and variant, which leaves 122 random bits, or about 5.3 × 10^36 possible values. The birthday problem puts the numbers in perspective:

• You need roughly 2.71 quintillion (2.71 × 10^18) v4 UUIDs for a 50% chance that any two match.
• At one billion UUIDs per second, it would take about 86 years to get there.
• After 103 trillion UUIDs, the chance of a single duplicate is still about one in a billion.

The math only holds when the bits are truly random. Duplicates in practice come from weak generators such as snippets built on Math.random, from bugs that reuse a value, and from test fixtures copied between environments. This page uses crypto.randomUUID() and crypto.getRandomValues(), the browser's cryptographically secure source. For v7 it follows RFC 9562's counter method, so UUIDs generated in the same millisecond still come out unique and in order.

How to Generate a UUID in Code

Most languages and databases ship a UUID function, so you rarely need a library for v4. Built-in v7 support is newer, so check your version.

crypto.randomUUID();                      // v4, secure contexts (HTTPS) only
import { randomUUID } from "node:crypto";  // Node.js

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

SELECT gen_random_uuid();  -- PostgreSQL 13+, v4
SELECT uuidv7();           -- PostgreSQL 18+, v7
SELECT UUID();             -- MySQL, returns a version 1 UUID

Guid.NewGuid();          // C#, v4
Guid.CreateVersion7();   // C#, v7, .NET 9+
UUID.randomUUID();       // Java, v4

uuidgen                          # random v4; macOS prints uppercase
uuidgen | tr '[:upper:]' '[:lower:]'

In MySQL, UUID_TO_BIN(UUID(), 1) stores the value in 16 bytes and swaps the time fields so that indexed v1 values cluster better. For v7 in JavaScript, the uuid package on npm exports a v7() function.

Using UUIDs as Test Data in QA

UUIDs solve a surprising number of testing problems because they are unique without any coordination between test runs:

• Unique fixtures: add a UUID to usernames, emails or order references (for example qa+<uuid>@example.com) so parallel CI jobs never trip over the same unique constraint.
• Idempotency keys: send the same UUID in an Idempotency-Key header on a retried POST and check that the payment or order is created only once.
• Correlation IDs: set a UUID in a request header such as X-Request-ID, then search every service's logs for it. Paste that ID into the bug report so developers can find the exact request.
• Seeding and cleanup: generate 100 IDs as a JSON array for fixture files, or as an SQL IN (…) list to select or delete exactly the rows a test created.
• Validator edge cases: feed your API the Nil UUID, the Max UUID, uppercase values, braces, missing hyphens and a v1 where a v4 is expected, and confirm it accepts or rejects each one on purpose.

When a test fails on a specific record, paste its ID into the validator above. A v7 or v1 ID tells you when the record was created, which often narrows down the deploy or the test run that produced it.