UUID generator (v4 and v7)

What is a UUID?

A UUID (universally unique identifier) is a 128-bit number used as an ID. Microsoft calls it a GUID. It is written as 32 hex digits in five groups, 8-4-4-4-12:

0190f4d2-6b3a-7c41-9a2e-5f1c8d7e4b90
              ^    ^
        version    variant

The first digit of the third group is the version. The first digit of the fourth group shows the variant. For standard UUIDs it is 8, 9, a or b, which means the bits 10. UUIDs are defined in RFC 9562 (2024), which replaced RFC 4122.

Any computer can create UUIDs without asking a central server, and they will not clash in practice. That makes them useful for database keys, file names, request IDs and offline apps that sync later.

UUID v4 vs v7 vs v1

Version 7 is laid out like this. The tool sets the version and variant bits exactly as RFC 9562 says.

| 48 bits: Unix ms | 4: ver=0111 | 12: rand_a | 2: var=10 | 62: rand_b |

When several v7 UUIDs are made in the same millisecond, this tool increases the random part by a random step. So each list comes out in strict ascending order, as RFC 9562 allows.

Can two UUIDs collide?

A v4 UUID has 128 bits, but 6 are fixed (4 for the version and 2 for the variant). That leaves 122 random bits, or 2¹²² ≈ 5.3 × 10³⁶ possible values.

The birthday problem gives the chance that any two of n random UUIDs match:

p ≈ n² ÷ (2 × 2^122)

• One trillion (10¹²) UUIDs: p ≈ 10²⁴ ÷ 1.06 × 10³⁷ ≈ 9 × 10⁻¹⁴.
• A 50% chance needs about 2.7 × 10¹⁸ UUIDs. At one billion per second, that takes about 86 years.

This only holds when the random bits are truly random. This tool uses the browser's secure generator (crypto.randomUUID or crypto.getRandomValues), not Math.random. For v7, only UUIDs made in the same millisecond can collide, and 74 random bits make that very unlikely too.

Why v7 is better for database keys

Most databases store primary keys in a B-tree index. Random v4 keys land at random places in that index. Each insert can touch a different page, so pages split, the index grows fragmented, and less of it stays in memory. With large tables, inserts slow down.

v7 keys increase over time, so new rows go to the end of the index, as with an auto-increment number. You keep the benefits of UUIDs (no central counter, IDs can be made on the client) and get sequential writes. A v7 key also tells you roughly when the row was created.

One caution: that timestamp is visible to anyone who sees the ID. If creation time is sensitive, use v4.

Tips

• Store UUIDs as 16 bytes (PostgreSQL uuid, MySQL BINARY(16)) rather than 36-character text.
• Compare in lower case. RFC 9562 says to output lower case and to accept either case on input.
• A UUID is not a secret. For password-reset links or API keys, use a dedicated random token, for example from the password generator.

Frequently asked questions

Last updated 11 October 2026. How we check our tools.