UUID Generator — RFC 4122 v4

How UUID Generation Works

A UUID (Universally Unique Identifier) is a 128-bit value, standardized by RFC 4122, formatted as 32 hexadecimal digits grouped into 8-4-4-4-12 blocks separated by dashes. The standard defines several versions that differ in how the bits are derived. Version 1 combines a timestamp with the generating machine's MAC address, which makes IDs sortable by creation time but leaks hardware identity. Version 4 — the version this tool generates — discards that approach entirely and fills the ID with random bits instead, aside from a handful of fixed bits that mark the version and variant.

Of the 128 total bits, UUID v4 uses 122 of them as genuine randomness (4 bits are fixed to indicate "version 4," and 2 more are fixed for the variant field). That gives 2^122 possible values — roughly 5.3 x 10^36. To put the collision odds in perspective: even generating a billion UUIDs every second, it would take on the order of 100 trillion years of continuous generation before the probability of any two colliding reached 50%, per the birthday paradox math that governs random identifier collisions. For virtually every practical application, that risk is treated as zero.

This tool uses crypto.randomUUID(), a browser API built on the Web Crypto API's cryptographically secure random number generator — the same underlying entropy source browsers use for generating TLS session keys. That's a meaningfully stronger guarantee than a UUID generated with Math.random(), which is a fast but statistically weaker pseudo-random source not intended for anything where unpredictability matters. Since generation happens via a browser API rather than a network call, every UUID is produced instantly and locally — nothing is transmitted anywhere.

In practice, UUID v4 shows up anywhere a system needs to create identifiers without a central authority handing out the next number. Database primary keys benefit from UUIDs when data is written from multiple sources or shards that can't coordinate on a single incrementing counter. Idempotency keys — attached to API requests so a retried request is recognized as a duplicate rather than processed twice — rely on the same collision-resistance property. Distributed tracing systems use UUIDs to tag a request as it moves across services, and offline-first applications use them to let a client create a record locally, with an ID guaranteed not to collide once it eventually syncs to a shared server.