Create single or batch UUIDs for records, logs, and request tracing.
UUID v7 is time-ordered, while v4 is random. Formatting options are applied after generation.
Understand the format
A UUID is a 128-bit identifier that any machine can generate independently, without asking a central service whether the value is already taken.
A UUID is 128 bits printed as 32 hexadecimal digits in five hyphen-separated groups of 8-4-4-4-12. Two of those digits are not random: the first digit of the third group encodes the version, and the first digit of the fourth group encodes the variant. In a version 4 UUID you will always see a 4 at that position and one of 8, 9, a, or b at the variant position, which leaves 122 bits of actual randomness.
Uniqueness therefore comes from probability rather than coordination. With 122 random bits, you would need to generate on the order of a billion UUIDs per second for roughly a century before a collision became likely. That is why services can mint identifiers offline, on a phone, or in a queue consumer without a shared sequence.
Version 4 is entirely random, which makes it excellent for correlation identifiers and terrible for database index locality. Because consecutive inserts land in random positions of a B-tree index, write-heavy tables suffer page splits and a larger working set.
Version 7, standardised in RFC 9562, puts a 48-bit Unix millisecond timestamp in the high bits and fills the rest with randomness. The result still looks like a UUID and remains globally unique, but values generated later sort after values generated earlier. That restores index locality and gives you a rough creation time for free, at the cost of revealing when the identifier was created.
Step by step
Identifiers are generated in your browser with crypto.randomUUID and crypto.getRandomValues. Nothing is requested from or reported to a server.
Worked examples
Input
version: v4, count: 2
Result
9f1c4a2e-6d3b-4f8a-9c21-7ae5b0d3f412 1b7e0c55-2f94-4a17-b0d8-6c3e9a15d720
The 4 at the start of the third group is the version nibble; the leading 9 and b of the fourth group are the variant bits.
Input
version: v7, count: 2
Result
0195a3f1-8c40-7b2e-8f31-2d9c4e7a10bb 0195a3f1-9028-7c6a-9d55-31be0f42a7c9
The first three groups encode the millisecond timestamp, so the two values sort in creation order as plain strings.
Reference
| Version | Content | Sortable by time | Typical use |
|---|---|---|---|
| v1 | Timestamp plus MAC address | Partly, after byte reordering | Legacy systems. Leaks the generating host. |
| v4 | 122 random bits | No | Correlation IDs, external references, test data. |
| v7 | 48-bit Unix ms timestamp plus randomness | Yes, lexicographically | Primary keys in write-heavy tables, event ordering. |
| Nil UUID | All zero bits | n/a | A defined placeholder: 00000000-0000-0000-0000-000000000000. |
Practical Guide
Troubleshooting
FAQ
In principle yes, in practice no, provided they come from a cryptographically secure random source. The risk becomes real only when a weak or poorly seeded generator is used, which is why this page uses the browser crypto API.
The specification says hexadecimal digits must be produced in lowercase but compared case-insensitively. Some Microsoft ecosystems display uppercase. Normalise on input if you compare them as strings.
They are a Microsoft registry and COM convention for GUIDs. The value is identical; only the surrounding text differs.
It is unique and unguessable, but it embeds a creation timestamp. If disclosing when a record was created is sensitive, use v4 externally and v7 internally.
It is a reasonable choice when records are created by many independent clients. Prefer v7 or another time-ordered identifier to avoid the index fragmentation that random keys cause on large tables.
Go deeper
