A version 4 UUID carries exactly 122 random bits — 2¹²² ≈ 5.3 × 10³⁶ possible values — inside a 128-bit, 36-character frame; the remaining 6 bits are the version nibble (the “4” starting the third group) and variant bits (8, 9, a or b starting the fourth). Press Generate below; each ID comes from crypto.randomUUID(), the browser's cryptographically secure generator.
The birthday bound puts a number on “unique enough”: you would need about 2⁶¹ ≈ 2.3 × 10¹⁸ v4 UUIDs — a billion per second for 73 years — before reaching a 50% chance of a single collision anywhere in the set. Per RFC 4122/9562, that is why v4 IDs are minted without any coordination between machines.
If you need IDs that sort by creation time, v4 is structurally the wrong version — no amount of generation luck makes random IDs ordered. That job belongs to UUID v7 (48-bit millisecond timestamp prefix), which this generator honestly does not produce; use a library like the uuid npm package server-side, and read the v4 vs v7 guide for when each fits. If two “identical” UUIDs ever appear in your system, suspect a cloned VM or copy-pasted row before suspecting the randomness.
Use v4 for identifiers that must reveal nothing: request IDs, idempotency keys, public tokens, file names, and any key where creation time is nobody's business.
This page is a focused view of theUUID Generator, which has the full set of options.
In theory yes, in practice no: with 122 random bits you would need roughly 2.3×10¹⁸ UUIDs for a 50% chance of one collision. Treat them as unique.
Yes — crypto.randomUUID() uses the browser's CSPRNG, per RFC 4122/9562 requirements for version 4. They are generated on your device and never transmitted.
That nibble encodes the version. A v4 UUID always reads 4 there, and the first character of the fourth group is 8, 9, a or b (the variant bits).