UUID generator
Version 4 (random) and version 7 (time-ordered) UUIDs, one or up to 1,000 at a time, in the format your code expects.
The format
A UUID is 128 bits, written as 32 hexadecimal digits in five groups of 8, 4, 4, 4 and 12. RFC 9562, published by the IETF in May 2024 to replace RFC 4122, keeps that layout and adds versions 6, 7 and 8. Two fields are fixed in every UUID of the standard variant: the version, the first digit of the third group, and the variant, the first digit of the fourth group, which is always 8, 9, a or b.
| Bits | Version 4 | Version 7 |
|---|---|---|
| 0–47 (first 12 digits) | 48 random bits | Milliseconds since 1 January 1970, UTC |
| 48–51 (13th digit) | Version, always 4 | Version, always 7 |
| 52–63 | 12 random bits | 12 random bits |
| 64–65 | Variant, binary 10 | Variant, binary 10 |
| 66–127 | 62 random bits | 62 random bits |
| Random in total | 122 bits | 74 bits |
So in 01a1266c-7f47-71fc-8111-14c257bd63b5 the 7 that starts the third group marks version 7, the 8 that starts the fourth group is the variant, and 01a1266c7f47 is the time: 1,791,646,007,111 milliseconds after the start of 1970, or 15:26:47.111 UTC on 10 October 2026. Paste any UUID into the inspector above to read it the same way. The 48-bit clock in version 7 runs out in the year 10889.
How likely a collision is
A version 4 UUID is one of 2122, about 5.3 × 1036, possible values. The chance that a set of n of them contains any repeat follows the birthday problem:
chance≈ 1 − e−n(n−1) ÷ (2 × 2122)1,000 UUIDs: 9.4 × 10−32
neededn ≈ √(2 × 2122 × ln(1 ÷ (1 − p)))p = 1 in 2: 2.7 × 1018
| Chance of at least one repeat | Version 4 UUIDs needed | In words |
|---|---|---|
| 1 in a trillion | 3.26 × 1012 | 3.3 trillion |
| 1 in a billion | 1.03 × 1014 | 103 trillion |
| 1 in a million | 3.26 × 1015 | 3.3 thousand trillion |
| 1 in 100 | 3.27 × 1017 | 327 thousand trillion |
| 1 in 2 | 2.71 × 1018 | 2.7 million trillion |
Making a billion version 4 UUIDs every second, it would take about 86 years to reach a 50% chance of a single repeat. In practice a collision is far more likely to come from a broken random source, such as a process forked without reseeding its generator or a non-cryptographic generator, which is why RFC 9562 recommends a cryptographically secure one.
Version 7 UUIDs can only collide within the same millisecond, where they differ in 74 random bits. A thousand made in one millisecond have a 2.6 × 10−17 chance of a repeat, and a million in one millisecond 2.6 × 10−11.
Version 4 or version 7 for database keys
Most databases keep primary keys in a sorted index. Version 4 values are scattered at random, so each new row lands somewhere in the middle of the index, touching a different page each time. Version 7 values start with the time, so new rows go in at the end, the way an auto-increment number does. RFC 9562 notes that the difference in index locality can be an order of magnitude or more.
| Version 4 | Version 7 | |
|---|---|---|
| Sort order | Random | Creation time, to the millisecond |
| Index inserts | Scattered | At the end |
| Reveals | Nothing | When it was made |
| Random bits | 122 | 74 |
| Best for | Public identifiers, anything that must not leak timing | Primary keys, logs, events, anything sorted by time |
RFC 9562 also recommends storing UUIDs as their 128-bit binary value where the database allows it rather than as 36 characters of text, which takes 288 bits. To keep a batch in order within one millisecond, the standard suggests a counter or extra clock precision; this tool sorts each list instead, which gives the same increasing order while keeping all 74 bits random.
Questions
Should I use version 4 or version 7?
Use version 7 for database keys and anything you sort or index, because new values are added at the end of the index instead of at random places. Use version 4 when the identifier must not reveal when it was made, or when RFC 9562 asks for it, as it does for identifiers involved in any security operation.
Can two UUIDs ever be the same?
In principle, yes; in practice, not with a good random source. You would need about 103 trillion version 4 UUIDs for a 1 in a billion chance of a single repeat among them. A version 7 repeat needs two UUIDs from the same millisecond to share 74 random bits, which for a thousand UUIDs in one millisecond has a chance of about 1 in 38 million billion.
Are uppercase, braces or no hyphens still valid?
RFC 9562 defines the standard text form as 32 hexadecimal digits in groups of 8-4-4-4-12 and allows uppercase, lowercase or mixed case. Braces, the plain 32-digit form and the urn:uuid: prefix are common alternatives. Many systems compare UUIDs as text, so pick one form and use it everywhere; lowercase with hyphens is the most widely accepted.
Can I use a UUID as a secret token or password?
No. RFC 9562 says implementations should not assume UUIDs are hard to guess and must not use them as security capabilities, such as identifiers whose mere possession grants access. Version 7 also reveals its creation time. For a secret, use the password generator.
Are the UUIDs sent or saved anywhere?
No. They are made in your browser with its cryptographic random number generator, and nothing is sent or stored. The inspector also works entirely in the page.
Why not use crypto.randomUUID()?
Browsers provide crypto.randomUUID() for version 4 only. This tool builds both versions from the same random bytes from crypto.getRandomValues(), setting the version and variant bits itself, so the two follow exactly the same layout rules.