How to use it
When the page opens, 10 version 4 UUIDs are already waiting. Under Generate UUIDs you can change the following.
- Version: choose “v4 (fully random)” or “v7 (time-ordered)”. A new set is generated as soon as you choose.
- How many: a whole number from 1 to 1000. If you enter something outside that range, it is set to 1 or 1000 when you leave the field.
- Uppercase, No hyphens, Braces { }: how the results are written.
- Generate: makes new values with the same settings.
- Copy all, Download .txt: take the full set of results, one per line. The downloaded file is named uuid.txt. The copy button on each line takes just that one.
If you generate more than 100, only the first 100 appear on screen until you click “Show all”. Copy all and the download always include every value, shown or not.
Further down, the UUID inspector takes a single UUID and shows its “Version”, “Variant” and “Embedded timestamp”.
How version 4 and version 7 differ
A UUID is a 128-bit value. Six of those bits are fixed positions that record the version and the variant. The versions differ in how they fill the other 122 bits.
| Position | Version 4 | Version 7 |
|---|---|---|
| First 48 bits | Random | Milliseconds since January 1, 1970 (UTC) |
| 4 bits | Version (4) | Version (7) |
| 12 bits | Random | Random in RFC 9562, but this tool uses them as a counter |
| 2 bits | Variant | Variant |
| 62 bits | Random | Random |
A version 4 value tells you nothing when you look at it. The price is that it has no sort order, so as a database primary key each new value lands somewhere in the middle of the index. That means more B-tree page splits and a lower cache hit rate.
A version 7 value starts with the time, so sorting the values as strings puts them in the order they were made. As a primary key, new values pile up at the end of the index. In exchange, the value gives away when it was created, down to the millisecond. For an identifier where outsiders shouldn’t be able to work out a sign-up time or an order time, version 4 is the right choice.
Version 4 values come from the browser’s crypto.randomUUID(), and the random part of version 7 is filled by crypto.getRandomValues(). Both are cryptographically secure random sources.
Why version 7 values from one batch come out in order
When you generate several version 7 UUIDs at once, the whole batch uses the same millisecond. Since the timestamps are identical, the order is settled by the 12-bit counter that follows.
- The first value in a batch starts the counter at a random number from 0 to 2047. Twelve bits can count up to 4095. Using only half of that leaves headroom against overflow.
- Each value after that raises the counter by 1. A batch holds 1000 values at most, so even from the highest starting point, 2047, it ends at 3046 and the counter never overflows.
- The last 62 bits are drawn fresh for every value.
Say the timestamp is January 1, 2026, 00:00:00.000 UTC and the counter starts at 2047. Three values in a row then begin 019b76da-a800-77ff, 019b76da-a800-7800 and 019b76da-a800-7801. The leading 7 of the third group is the version, and the three digits after it are the counter.
The counter does not carry over from one batch to the next. Clicking “Generate” again starts over with the time at that moment, so a later batch sorts after an earlier one by its timestamp. If the device clock was set back in between, that order no longer holds.
How likely a collision is
Version 4 has 122 random bits. By the birthday problem, you would have to generate about 2.7 × 10^18 values before the chance of even one duplicate reaches 50%. At a billion values a second, that takes about 86 years.
The version 7 values from this tool have 62 bits that are drawn fresh each time. Within one batch the counters all differ, so values can’t coincide. Two values made in the same millisecond on different devices or in different tabs coincide only if both the counter and all 62 random bits are the same.
What the inspector reads
Put 018f4d2e-7c3a-7b21-9e2f-1a2b3c4d5e6f into the inspector and it reports version 7, the variant “RFC 9562 (standard)” and an embedded timestamp of May 6, 2024, 09:14:03 UTC. The time is shown in this browser’s time zone, so in a UTC+9 time zone it reads 6:14:03 PM.
- Version is the first digit of the third group (the 13th hex digit), shown as the number it is. A version number the standard doesn’t define is shown as it is.
- Variant is decided by the bits of the first digit of the fourth group.
| Shown on the page | First digit of the fourth group | Meaning |
|---|---|---|
| NCS (legacy) | 0–7 | Kept for compatibility with the old NCS scheme |
| RFC 9562 (standard) | 8, 9, a, b | The standard UUID in use today |
| Microsoft (legacy GUID) | c, d | For compatibility with old Microsoft GUIDs |
| Reserved for future use | e, f | Not defined yet |
- When every digit is 0 the value is tagged “Nil UUID”, and when every digit is f it is tagged “Max UUID”. RFC 9562 describes Nil as a way to say “no value” and Max as a marker for things like the end of a list. Going by their digits, Nil is displayed as version 0 with the NCS variant and Max as version 15 with the reserved variant.
The inspector looks at shape only. Anything with 32 hex digits gets through, so passing does not mean the UUID was ever really issued. If you edit a value by hand and its version digit is 7, the timestamp is read from whatever digits are in those positions.