UUID Generator

A UUID is 128 bits written as 32 hexadecimal digits in a fixed 8-4-4-4-12 layout, and almost all of those bits are simply random. A version 4 UUID sets aside just six of them for bookkeeping: four bits in the third group name the version itself, and two bits at the top of the fourth group declare the variant — the dialect of UUID the remaining bits follow. Everything else, 122 bits across, comes straight from a random source. That split is why v4 UUIDs look so irregular next to the time-structured v1: there is nothing in a v4 to read except chance, deliberately.

The forcing is mechanical, and it is the whole difference between a random 128-bit value and a valid UUID. Take the most extreme input possible — sixteen bytes of 0xff — and watch the two reserved fields absorb it: the first byte of the third group, 0xff, keeps its low nibble and has its high nibble set to 4, giving 0x4f; the first byte of the fourth group, also 0xff, is masked to its low six bits with 0x3f and then given the 10 prefix, giving 0xbf. Every other bit passes through untouched:

The all-zeros row shows the same rule from the other side: an input with no randomness at all still comes out shaped like a legal v4, with the '4' in position fourteen and the '8' in position nineteen marking version and variant. You can read any v4 UUID that way. Position fourteen is always 4, and position nineteen is always one of 8, 9, a or b — the four hex digits whose leading bits are 10. A string that breaks either rule is not a v4 UUID, whatever produced it.

The 122 free bits are the entire uniqueness budget. Written out they give 2^122, or about 5.3 × 10^36 possible values — enough that the random draw, not some central authority, is what keeps two independently generated UUIDs apart. That is the design's central bet, and the next section puts numbers on how safe the bet is.

The honest answer comes from the birthday paradox, the same bit of probability that says a room of twenty-three people probably contains a shared birthday. Collisions among UUIDs are governed not by how many exist in total but by how many you generate: the chance of any two matching grows with the square of the count, divided by the size of the space. Squaring is what makes big spaces feel smaller than they are — and 2^122 is big enough to absorb the squaring many times over.

Put concrete numbers on it. Generate one billion UUIDs — a table with a billion rows, each keyed by its own v4 — and the probability that any two of them match is about one in ten quintillion. Keep going to 103 trillion and the odds of a single collision reach only one in a billion. The count needed for a fifty-fifty chance of even one collision anywhere is about 2.71 quintillion, or 2.71 × 10^18 — a figure no production system on earth has emitted. That is what 'globally unique' means in practice: a bet on scale, safe because 2^122 outlasts any scale anyone will reach.

Two honest caveats sit under those numbers. First, they assume a genuine random source — a seeded pseudo-random generator with a small state would quietly shrink the space to that seed's size, which is exactly why this page uses the browser's cryptographic generator rather than Math.random. Second, 'no collision will occur' is a probability, not a law. Databases answer that distinction correctly and cheaply: a unique index on the column turns the one-in-billions into a constraint violation you will never see, instead of a silent overwrite you might.

Version is a real field, so UUIDs carry their own pedigree: reading the nibble in position fourteen tells you what generated the rest. The original RFC 4122 defined v1 through v5, and RFC 9562 added v6 through v8 in 2024. In practice three versions cover nearly everything seen in the wild, and they differ in exactly one design question — where uniqueness should come from.

The trade-offs line up neatly against that one question. v1 buys time-ordering and pays with privacy: every ID exposes the moment and the machine that made it, and the embedded MAC address once let the Melissa virus of 1999 be traced to the specific computer that created an infected document. v4 pays nothing and gets nothing but uniqueness — sort a table of v4 keys and the order is noise, which is why databases with v4 primary keys develop index fragmentation under heavy insert load. v7 is the synthesis: a millisecond timestamp in the high bits keeps newly created IDs adjacent in the index while 74 random bits carry the uniqueness, giving up a little entropy — 74 bits instead of 122 — for that ordering.

This page generates v4 only, on purpose. A browser cannot produce v1 honestly — it would have to fake the MAC address — and v7 belongs in the hands of the system generating identifiers at database scale, where the ordering actually pays. For keys minted in a client, a config file, a test fixture or a URL, v4 is the version with no footguns: nothing to leak, no clock to skew, nothing to configure.

Every format this page emits carries the same 128 bits; they differ only in dress. The canonical form is lowercase with hyphens, which is what RFC 4122 itself prints and what this page shows by default. Uppercase is the Microsoft convention — .NET's Guid.NewGuid().ToString() produced capitals for years — and comparisons must be case-insensitive wherever values from both worlds meet. The brace-wrapped form, {…}, is how COM, the Windows registry and older Visual Studio tooling print GUIDs, and parsers in that ecosystem accept and often require the braces. The bare 32-character form with no hyphens appears where a schema or a column has no room for punctuation.

A few things are worth knowing before mixing them. Hyphens are presentation, not structure — the underlying value is the same 32 hex digits either way, which is why the no-hyphens form is trivially recoverable from any other. Case, likewise, is cosmetic: treating 'ABC' and 'abc' as different UUIDs is a classic integration bug, and the fix is to normalize one way at every boundary. Parsers disagree about tolerance, though — some accept bare hex or braces, some demand hyphens, some fold case and some do not — so the safe habit is to emit the canonical hyphenated lowercase form unless the receiving system asks for something else, and to use the format selector on this page to match whatever it asks for.