UUID Generator (GUID): v4 and v7, in Bulk

About this tool

This UUID generator makes version 4 (random) or version 7 (time-ordered) UUIDs, up to 1,000 at a time, as defined in RFC 9562, which replaced RFC 4122 in May 2024. Version 4 values come from the browser's crypto.randomUUID(), which uses a cryptographically secure random number generator. Version 7 values are built by the page itself, as described below. You can reformat the batch, copy it or download it as a text file. The decoder reads the version, variant and embedded time out of any UUID. Nothing is sent to a server.

How to use it

1. Pick v4 or v7 and enter how many you need (1 to 1,000).
2. Click Generate UUIDs. Tick Uppercase, Braces or No hyphens to reformat the same batch without regenerating it.
3. Copy all or Download .txt (one UUID per line).
4. To inspect an existing ID, paste it into Decode a UUID.

UUID v4 vs v7 for database keys

A version 4 UUID is 122 random bits plus 6 fixed version and variant bits. New values land at random places in a sorted index. RFC 9562 says plainly that non-time-ordered versions such as UUIDv4 "have poor database-index locality." A version 7 UUID starts with a 48-bit Unix timestamp in milliseconds, so IDs created later sort after earlier ones. Inserts go to the end of a B-tree index, as with an auto-increment column, but you still don't need a central counter. RFC 9562 says systems that don't involve legacy UUIDv1 should use UUIDv7 rather than v1 or v6.

The trade-off is privacy. Anyone holding a v7 ID can read when it was made (the decoder above does exactly that). Use v4 when the ID is public and its creation time should stay private, such as an invite link or a document shared with a customer.

How v7 is generated here

To keep IDs in order within a batch, the tool follows Method 1 of RFC 9562 Section 6.2, a fixed-length dedicated counter placed right after the timestamp. On each new millisecond the 12-bit counter starts at a random value with its top bit cleared, which leaves room before it overflows. Each further UUID in the same millisecond adds 1. If the counter overflows, the timestamp is moved 1 ms ahead, which the RFC permits. If the system clock steps backwards, the last timestamp is reused. So every UUID the page makes sorts after the one before it, even in a batch of 1,000 created within the same millisecond.

Reading a UUID: version and variant digits

A UUID is 128 bits written as 32 hexadecimal digits in groups of 8-4-4-4-12. The first digit of the third group is the version: in 3fa85f64-5717-4562-b3fc-2c963f66afa6 it is 4. The first digit of the fourth group holds the variant. For standard UUIDs its top two bits are 10, so that digit is 8, 9, a or b. Two special values are never generated: the Nil UUID (all zeros) and the Max UUID (all fs). RFC 9562 allows uppercase, lowercase or mixed case, but a plain string comparison in code treats A and a as different, so pick one case and stick to it.

How likely is a collision?

A v4 UUID has 2¹²², about 5.3 × 10³⁶, possible values. By the birthday approximation, the chance of at least one duplicate among n UUIDs is about 1 − exp(−n² / (2 × 2¹²²)). The figures below were computed in Python from that formula.

A v7 UUID can only collide with another made in the same millisecond, because the timestamps differ otherwise. In practice, duplicates come from broken random generators or copied IDs, not bad luck.

GUID vs UUID

They are the same thing. RFC 9562 opens by defining UUIDs, "also known as" GUIDs (Globally Unique IDentifiers), the name Microsoft uses. The differences are in presentation. .NET's Guid format specifiers include D (hyphens, the standard form), N (32 digits, no hyphens), B (braces) and P (parentheses). Windows tools often show GUIDs in uppercase with braces, which the format options here reproduce. RFC 9562 also notes that COM GUIDs are saved in little-endian byte order. Raw 16-byte GUID values from Windows therefore have their first three groups byte-swapped compared with the text form.

Worked example

The decoder opens with 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. The third group starts with 7, so it is version 7, and the fourth group starts with 9 (binary 1001), so it is the standard variant. Its first 12 hex digits, 017f22e279b0, are 1,645,557,742,000 milliseconds, and the tool shows the timestamp as 2022-02-22T19:22:22.000Z. You can check that figure with the Timestamp Converter. Everything after the timestamp, apart from the version and variant bits, is counter or random data.

Edge cases and common mistakes

• Storing UUIDs as text. The 36-character string is more than twice the 16 bytes of the value. Use a native uuid or 16-byte binary column where your database has one.
• Trusting v7 order across machines. Ordering is only as good as each server's clock. IDs from two servers whose clocks disagree can interleave out of creation order.
• Treating a UUID as a secret. A v4 UUID is hard to guess, but it is an identifier, not a password or access token. For secrets, use the Password Generator.
• Over 1,000 at once. The count is capped at 1,000. Generate several batches; v7 order is kept between them.

For the basics, including where the other versions came from, read What Is a UUID? Versions, Format and Collision Odds. If you need a fingerprint of some content rather than a fresh ID, the Hash Generator computes SHA-256.