UUID v4 Generator: Generate RFC 4122 Random UUIDs Online

A UUID v4 is a 128-bit value where all but 6 bits are random. Those 6 fixed bits are what make it a "v4" specifically, rather than any of the other seven UUID versions defined by RFC 9562 (the current spec, which obsoletes the older RFC 4122 — the two names get used interchangeably in the wild, and both describe the same 128-bit layout). For the full background on what a UUID is, how the five hyphen-separated groups work, and how v4 compares to v7 and to a .NET GUID, see the UUID Generator guide. This article stays narrowly on v4: what its bits actually encode, why that makes collisions a non-issue, and the one implementation detail worth getting right.

Two positions in the 32 hex digits are reserved by the spec. The first hex digit of the third group is the version, fixed to 4 for every v4 UUID. The first hex digit of the fourth group encodes the variant — its top two bits are fixed to 10, which in hex means that digit is always 8, 9, a, or b. Everything else — 122 of the 128 bits — is filled with random data. Nothing about a v4 UUID is derived from a timestamp, a MAC address, or a namespace; it is, structurally, as close to pure randomness as an identifier format gets.

f47ac10b-58cc-4372-a567-0e02b2c3d479
                     ^                 ^
              version nibble     variant bits
              "4" → fixed        "a" (top 2 bits "10") → fixed

Group 3: "4372"
  4    → 0100  →  version, always 4 for UUID v4
  372  → 12 more random bits

Group 4: "a567"
  a    → 1010  →  top 2 bits "10" fixed (variant), bottom 2 bits random
  567  → 12 more random bits

Total: 6 bits fixed (version + variant), 122 bits random

That 6-and-122 split is the entire definition of UUID v4. A generator that gets those 6 bits right and fills the rest with real randomness has produced a spec-compliant, RFC 4122 UUID — full stop, regardless of which library or language produced it.

122 bits of randomness is a big enough space that no central authority needs to hand out IDs to prevent duplicates — any two machines, generating UUID v4s independently and offline, can trust the math instead of coordinating. That's the entire value proposition of a random UUID generator over an auto-incrementing counter: no round trip, no lock, no shared state, and still an effectively unique value.

The birthday paradox is the right lens for "how unique is unique enough." With n possible values, the number of items you need to generate before there's a 50% chance any two of them collide is roughly 1.177 × √n — not n itself, which is the counterintuitive part. For UUID v4, n is 2¹²², so that 50% threshold lands at approximately 2.71 quintillion (2.71 × 10¹⁸) generated UUIDs. To put that number somewhere concrete: generating a billion v4 UUIDs every second, nonstop, it would take roughly 86 years to reach even a 50% chance of one single collision, anywhere, across the entire batch. Practically, if a duplicate UUID v4 turns up in real application data, the far more likely explanation is a code bug — an ID generated once and reused across rows, or hardcoded as a placeholder that never got replaced — not an actual collision.

The one thing worth being precise about: the collision math above assumes every one of those 122 bits is drawn from a source with no exploitable pattern. In a browser, that means crypto.getRandomValues()— part of the Web Crypto API, backed by the operating system's CSPRNG (cryptographically secure pseudo-random number generator). It does not mean Math.random().

Math.random()is explicitly not specified to be cryptographically random — the ECMAScript spec leaves its underlying algorithm implementation-defined, and every major engine uses a fast, statistically-good-but-predictable PRNG (V8 currently uses xorshift128+). Given enough consecutive outputs, that internal state can be reconstructed and future values predicted. That's a real problem for anything security-adjacent — session tokens, password-reset links, idempotency keys an attacker might try to guess — and it's exactly the gap that made some early "UUID generator" npm packages and Stack Overflow snippets quietly non-spec-compliant: they produce a string shaped like a UUID, with the version and variant nibbles set correctly, but backed by Math.random() for the random bits. It looks identical to a real v4 UUID and it is not random in the way the collision math above requires.

// Correct: cryptographically secure, spec-compliant v4 generation.
const id = crypto.randomUUID();

// What crypto.randomUUID() does under the hood, roughly:
// crypto.getRandomValues() fills 16 random bytes, then the version
// and variant nibbles are overwritten to their fixed values.

// Do not do this: Math.random() is not a CSPRNG.
// function badUuidV4() { ... built on Math.random() ... }

crypto.randomUUID()is built into every modern browser and into Node.js, requires no library, and always produces a correct v4 UUID — it's only available in a secure context (HTTPS or localhost) because it's part of the Web Crypto API. If a UUID library or generator doesn't document which random source it uses, that's worth checking before relying on it for anything where unpredictability actually matters.

v4's defining trade-off is that it carries zero embedded information — no timestamp, no sequence, no hint about when or in what order it was generated — in exchange for that plain, non-leaking randomness. A few cases where that's exactly what's wanted:

• Primary keys where insert order doesn't matter.Not every table benefits from a sortable key — a lookup table, a join table, or any row that's always fetched by exact ID rather than range-scanned by recency is a fine fit for v4. (For a table that isqueried by insert order at scale, v7's timestamp prefix avoids the B-tree fragmentation a random v4 key causes — see the pillar guide's comparison for that trade-off in full.)
• Request and trace IDs. A v4 UUID attached to an incoming request and threaded through logs, spans, and downstream service calls gives every hop a shared, collision-free correlation ID with no coordination required between services — and no risk that the ID itself leaks when the request was made.
• Idempotency keys for API calls.A client generates a v4 UUID once per logical operation and sends it with a payment, an order submission, or any request that must not double-apply if retried. The server treats a repeated key as "already handled" rather than a new request — a pattern that depends entirely on the key being unpredictable and unique, which is precisely what a correctly generated v4 UUID guarantees.

For a one-off value or a batch to paste into a fixture, a browser tool beats writing a script. GenKitLab's UUID Generator generates cryptographically random UUID v4 and time-sortable UUID v7 in bulk, then lets you copy the batch as a list, a JSON array, or a SQL insert statement. Generation happens with crypto.getRandomValues() — never Math.random() — and runs entirely client-side: nothing you generate is uploaded, logged, or transmitted anywhere.

To generate one in code instead — Python's uuid.uuid4(), crypto.randomUUID() in JavaScript, or gen_random_uuid() in Postgres — plus the full v4-vs-v7 decision framework and GUID comparison, see the UUID Generator guide.