UUID v4 vs v7, and How to Generate a UUID
What a UUID is and how it is written, how version 4 (random) differs from version 7 (time ordered), when to pick each, and how to generate and inspect UUIDs in your browser.
A UUID is a 128-bit identifier, written as 32 hex digits in five groups of 8, 4, 4, 4 and 12 (550e8400-e29b-41d4-a716-446655440000). A version 4 UUID is 122 random bits, while a version 7 UUID starts with the Unix time in milliseconds, so version 7 values sort by creation time and version 4 values do not.
Use v7 when you want identifiers that sort in the order they were made, and v4 when you only need a unique value. To make one, open the UUID Generator & Inspector, choose a version and press Generate UUIDs.
What is a UUID and how is it written?
A UUID (Universally Unique IDentifier, also called a GUID) is 128 bits long. The usual text form, which RFC 9562 calls hex-and-dash, writes it as 32 hex digits in groups of 8, 4, 4, 4 and 12, joined by hyphens: 00112233-4455-6677-8899-aabbccddeeff. The groups are 4, 2, 2, 2 and 6 bytes. The hyphens are only formatting, so the same UUID is also written as 00112233445566778899aabbccddeeff, and the case of the digits does not matter.
RFC 9562 replaced RFC 4122 in May 2024. It added version 7, a Unix-time based UUID, along with versions 6 and 8.
Where do the version and the variant sit in a UUID?
The version is the top 4 bits of byte 6, which is the first hex digit of the third group. In 550e8400-e29b-41d4-a716-446655440000 it is the 4 of 41d4, so this is a version 4 UUID. The variant is the top bits of byte 8, the first hex digit of the fourth group. The RFC's variant is bits 10, so that digit is 8, 9, a or b, and here it is the a of a716.
| Leading bits | Variant | Meaning |
|---|---|---|
| 0xxx | NCS (reserved) | Reserved for backward compatibility with NCS. The nil UUID has this variant. |
| 10xx | RFC 9562 | The variant defined by the RFC. Every v4 and v7 UUID uses it, so the first digit of the fourth group is 8, 9, a or b. |
| 110x | Microsoft (reserved) | Reserved for backward compatibility with Microsoft. |
| 111x | Future (reserved) | Reserved for future definition. The max UUID has this variant. |
This is the table the inspector uses, so a UUID such as 12345678-1234-1234-c234-123456789012 shows the variant Microsoft (reserved).
What is a version 4 UUID?
A version 4 UUID is random. The generator takes 16 random bytes and overwrites the six version and variant bits, which leaves 122 random bits.
| Field | Size | What it holds |
|---|---|---|
| Random | 122 bits | Everything except the six fixed bits |
| Version | 4 bits | 0100, so the first digit of the third group is 4 |
| Variant | 2 bits | 10, so the first digit of the fourth group is 8, 9, a or b |
The fixed bits are easy to see if you feed in the extremes. All-one bytes give ffffffff-ffff-4fff-bfff-ffffffffffff and all-zero bytes give 00000000-0000-4000-8000-000000000000: everything is random except the 4 and the 8, 9, a or b.
What is a version 7 UUID?
A version 7 UUID begins with the Unix time in milliseconds, and the rest is random apart from the version and variant bits. The RFC calls the timestamp field unix_ts_ms.
| Field | Size | What it holds |
|---|---|---|
| unix_ts_ms | 48 bits | The Unix time in milliseconds, big-endian, in the first 12 hex digits |
| ver | 4 bits | 0111, so the first digit of the third group is 7 |
| rand_a | 12 bits | Random in this generator |
| var | 2 bits | 10 |
| rand_b | 62 bits | Random in this generator |
For example, 1793188800000 ms is 12:00:00 UTC on 28 October 2026, and its first 48 bits are 01a18261-a600. With all-zero random bytes the UUID is 01a18261-a600-7000-8000-000000000000, and with all-one random bytes it is 01a18261-a600-7fff-bfff-ffffffffffff. The inspector reads the timestamp back from either one.
Because the time comes first, version 7 UUIDs from different milliseconds sort in time order, and the RFC says they are designed so that databases can sort them as opaque raw bytes. Two UUIDs made in the same millisecond are different, because the bits after the timestamp are random, but they are not in the order they were made unless an implementation adds a counter. The UUID Generator sorts a version 7 batch, so the list comes out in ascending order.
UUID v4 or v7: which should I use?
| Version 4 | Version 7 | |
|---|---|---|
| Random bits | 122 | 74 (12 in rand_a and 62 in rand_b) |
| Starts with | Random digits | The Unix time in milliseconds |
| Sorts by creation time | No | Yes, as raw bytes or as text |
| Shows when it was made | No | Yes, anyone with the UUID can read the time |
| Made in the same millisecond | No order at all | Different, but not in creation order unless a counter is added |
- Pick v7 when you want identifiers that sort by creation time, for example as database keys, in logs, or in anything you list newest-last. RFC 9562 recommends v7 over the older time-based versions 1 and 6 when there is no legacy reason to keep them.
- Pick v4 when you only need a unique value and do not want it to carry a time. A v7 UUID shows when it was made to anyone who has it, and the inspector prints that time as an ISO date.
The RFC does not say to use v7 instead of v4: it recommends v7 over v1 and v6. Which of v4 and v7 suits you depends on whether you want the time order and can accept the time being visible.
What are the nil and max UUIDs?
The RFC defines two special UUIDs. The inspector recognizes both:
| UUID | The inspector shows | Meaning |
|---|---|---|
| 00000000-0000-0000-0000-000000000000 | Nil UUID (version 0), NCS (reserved) | Every bit is zero |
| ffffffff-ffff-ffff-ffff-ffffffffffff | Max UUID (version 15), Future (reserved) | Every bit is one |
How likely is a UUID collision?
RFC 9562 gives no collision figure. It says implementations should use a cryptographically secure random number generator so that values have a low likelihood of collision, and also that true global uniqueness cannot be guaranteed. You can work out the odds for version 4 yourself with the usual birthday approximation: with 122 random bits you would need to generate about 2.7 quintillion (2.7 × 1018) UUIDs for a 50% chance of one duplicate, and about 103 trillion (1.03 × 1014) for a one in a billion chance. That assumes the random bits are really random, which is why the generator uses crypto.getRandomValues.
For version 7, a collision needs the same millisecond and the same 74 random bits.
A UUID is not a secret. RFC 9562 says implementations should not assume UUIDs are hard to guess and that they must not be used as security capabilities, meaning identifiers that grant access just by being possessed.
What is specific to the UUID Generator & Inspector?
- It makes version 4 and version 7 UUIDs, 1 to 100 at a time, with the random bits from
crypto.getRandomValues. - You can show them in uppercase or without hyphens. Each UUID has a copy button, and Copy all copies the whole list, one per line.
- A version 7 UUID puts the Unix time in milliseconds in its first 48 bits, and the generator sorts a version 7 batch so the list comes out in ascending order.
- The inspector reads a UUID with or without hyphens, in any case. It shows the version, the variant, whether it is the nil or the max UUID, and for versions 1 and 7 the timestamp in milliseconds and as an ISO date. Version 1 also shows its raw 100-nanosecond timestamp, clock sequence, and hexadecimal node identifier. The node may be randomly generated and does not necessarily identify a physical device.
- Besides the plain 32-digit forms, it accepts a UUID wrapped in braces, such as
{550e8400-e29b-41d4-a716-446655440000}, or with aurn:uuid:prefix, and inspects it the same as the bare value. - Everything runs in your browser, and nothing you generate or paste is uploaded.
Try the UUID Generator & Inspector
Open the UUID Generator & Inspector, choose UUID v7, generate a batch and paste one of the results into the inspector to read its timestamp. Then paste 550e8400-e29b-41d4-a716-446655440000 to see version 4 and the RFC 9562 variant.
How to generate a UUID
1. Choose version 4 or version 7
In the UUID Generator & Inspector, pick UUID v4 for 122 random bits and nothing else, or UUID v7 for a UUID that starts with the Unix time in milliseconds and so sorts by creation time.
2. Set the quantity
Enter a quantity from 1 to 100. The random bits come from crypto.getRandomValues in your browser.
3. Pick the format and generate
Tick Uppercase or No hyphens if you need them, then press Generate UUIDs. A version 7 batch is sorted so the list comes out in ascending order.
4. Copy one UUID or the whole list
Each UUID has its own copy button, and Copy all copies the list with one UUID per line.
5. Inspect a UUID you already have
Paste a UUID, with or without hyphens and in any case, into the inspector to see its version, its variant, whether it is the nil or max UUID, and for versions 1 and 7 the timestamp in milliseconds and as an ISO date. Version 1 also shows the raw 100-nanosecond timestamp, clock sequence, and node identifier; the node may be randomly generated.
// Frequently Asked Questions
What is the difference between UUID v4 and v7?
A version 4 UUID is 122 random bits plus the version and variant bits. A version 7 UUID starts with a 48-bit Unix timestamp in milliseconds, so UUIDs made later sort later, and the bits after the timestamp are random apart from the version and variant.
Should I use UUID v4 or v7?
Use v7 when you want identifiers that sort by creation time, such as database keys, and v4 when you only need a unique value and do not want it to carry a time. RFC 9562 recommends v7 over the older time-based v1 and v6 where there is no legacy need for them.
How do I generate a UUID?
Open the UUID Generator & Inspector, choose UUID v4 or UUID v7, set a quantity from 1 to 100 and press Generate UUIDs. Everything runs in your browser and the random bits come from crypto.getRandomValues.
Can two UUIDs be the same?
In theory yes, but with 122 random bits a version 4 collision is very unlikely: by the standard birthday approximation you would need to generate about 103 trillion UUIDs for a one in a billion chance of a single duplicate. RFC 9562 gives no collision figure, and it says true global uniqueness cannot be guaranteed.
Is a UUID safe to use as a secret token?
No. RFC 9562 says implementations should not assume UUIDs are hard to guess, and that UUIDs must not be used as security capabilities, meaning identifiers that grant access just by being possessed.