UUID generator

What a UUID is and how it's structured

A UUID is a 128-bit number written as 32 hexadecimal digits in the familiar 8-4-4-4-12 pattern, e.g. f47ac10b-58cc-4372-a567-0e02b2c3d479. Its whole purpose is to let completely independent systems mint identifiers — database rows, API resources, event IDs, uploaded file names, message keys — that won't collide without ever coordinating with each other. There is no central server handing out the next number; each generator just picks a value from a space so vast that duplicates are effectively impossible. Two of those 128 bits encode the "variant" and four encode the "version", which is why a v4 UUID always has a 4 at the start of the third group and one of 8, 9, a or b starting the fourth.

The versions, and which to use

The version says how the bits are filled. v4 is pure randomness (122 random bits) — the default, and what this tool generates. v1 mixes a timestamp with the machine's MAC address, so it sorts by time but leaks where and when it was created. v3 and v5 hash a namespace plus a name, so the same input always produces the same UUID — handy for deriving a stable ID from existing data. v7 is the modern favourite for database keys: it puts a millisecond timestamp in the high bits and randomness in the rest, so the IDs are globally unique and sort in creation order. As a rule of thumb, reach for v4 when you just need a unique token and v7 when those tokens become primary keys.

Why collisions don't happen in practice

With 122 random bits, the number of v4 UUIDs you'd need before a 50% chance of any two matching is about 2.7 quintillion. To put that in perspective, you could generate a billion UUIDs per second for a century and the odds of a single collision would still be negligible. That is what makes them safe to create offline, on the client, or across a fleet of servers that never talk to each other — the maths, not a coordinator, guarantees uniqueness. The one caveat is that uniqueness depends on good randomness, which is why this tool uses the cryptographically secure crypto.randomUUID() rather than Math.random().

UUID vs. a sequential ID — and privacy

UUIDs aren't always the right choice. A plain auto-increment integer is smaller, indexes faster, and is easier to read in logs — fine when a single database owns the counter. UUIDs win when there is no single owner, when clients must create records offline and reconcile later, or when you specifically don't want an ID to reveal how many records exist (an integer id=4096 tells a competitor your table size; a UUID tells them nothing). Whatever you generate here is produced entirely in your browser and never transmitted. Need a different kind of token? The password generator makes human-usable secrets and the hash generator derives fixed-length fingerprints from existing data. Generating UUIDs in code? Our guide to generating a UUID in JavaScript covers crypto.randomUUID(), a v4 fallback, and why Math.random() is the wrong tool.