UUID v4 generator
Version 4 is the UUID almost everyone means by “a random UUID” — 122 bits of cryptographically random data and nothing else. Generate a batch below, or read on for exactly how the 122 bits are laid out and why it is still the right default for most identifiers.
Generate v4 UUIDs
What makes a UUID version 4
Take 16 bytes (128 bits) of cryptographically random data, then overwrite exactly six of those bits: force the top nibble of byte 7 to 0100 (the digit 4, marking the version) and force the top two bits of byte 9 to 10 (marking the RFC 9562 variant). Format the result as 32 hex characters split 8-4-4-4-12 and you have a v4 UUID: 2f1e9c3a-7b6d-4e12-9a3c-5d8f0b1e2a44.
That leaves 122 bits genuinely random out of the 128 total — the other 6 are fixed by definition, on every v4 UUID that has ever been generated by anyone.
Why v4 is still the right choice for a lot of identifiers
Version 7 gets attention because it sorts, but sorting by creation time is a feature you have to actually want. A v4 UUID's defining property is the opposite: it carries no information whatsoever beyond the fact that it is a UUID. Nothing about a v4 value reveals when it was minted, in what order relative to any other v4 value, or on which machine.
That makes v4 the safer default for anything where leaking approximate creation time is undesirable — password-reset tokens, invite codes, session identifiers, publicly visible resource IDs in a URL. A v7 identifier used for the same purpose would let an outside observer infer roughly when the underlying record was created, purely from its ID.
Collision odds for v4, worked through
122 random bits gives 2122 ≈ 5.3 × 1036 possible v4 values. The birthday-bound approximation for a 50% chance of at least one collision anywhere in a generated set is n ≈ √(2N ln 2), which works out to about 2.7 × 1018 UUIDs — 2.7 quintillion. Generating a billion a second nonstop, that threshold is roughly 86 years away. A far more realistic pace — one new v4 UUID every millisecond, continuously — would still take about 86 million years to reach it.
What actually causes real-world collisions is not the random-number math catching up — it is a broken RNG, a copy-pasted hard-coded value reused across records, or code that accidentally seeds a non-cryptographic generator the same way twice. Use crypto.getRandomValues or crypto.randomUUID, never Math.random, and the birthday bound is not something you will realistically hit.
v4-specific questions
Is UUID v4 still a good default choice in 2026?
Yes, for the common case of an identifier that carries no information about when it was created. v4 is not deprecated and RFC 9562 keeps it as one of the two versions worth defaulting to, alongside v7. It remains the right choice whenever timing privacy matters or you have no reason to want sort order.
How many random bits does a v4 UUID actually have?
122 of its 128 bits. The remaining 6 bits are fixed: 4 bits for the version marker (always 0100) and 2 bits for the variant marker (always 10). Those 6 fixed bits are why a v4 UUID is sometimes described as having “122 bits of entropy” rather than the full 128.
Can I turn a v4 UUID into a shorter identifier safely?
Only if you re-derive it from the full 128-bit value, and only if you understand what you are trading away. Truncating a v4 UUID's printed string to fewer characters throws away random bits and increases collision risk quickly, because collision probability scales with the square of how much of the space you have discarded. If length is the real problem, base64- or base32-encoding the full 16 bytes gives a shorter string (22 or 26 characters) without losing any of the randomness — truncating the hex string does not.
Why do some v4 UUIDs I see online start with specific patterns like “00000000”?
Those are hand-crafted placeholder values used in documentation and examples — the all-zero UUID (nil UUID) and similar patterns are deliberately memorable stand-ins, not something a real random generator would produce except by the same astronomically small chance as any other specific 122-bit value. A genuine v4 UUID generated here will not follow any visible pattern.