About UUID Generator
Generate UUID v1, v3, v4, v5, v6 and v7 in the browser for testing, stable namespaces, sortable IDs and development workflows.
Common use cases
- Create random or sortable IDs
- Generate stable namespace-based UUIDs
- Prepare demo data, fixtures and placeholders
How to use
- Choose the UUID version that matches your scenario.
- Set count and namespace/name options when needed.
- Generate, review, copy or download the result batch.
What a UUID actually contains
A UUID is 128 bits, normally written as 32 hexadecimal digits in a 8-4-4-4-12 pattern. Those bits are not all free. Four bits encode the version, and two or three bits encode the variant, which marks the layout defined by RFC 4122 and its successor RFC 9562. In a version 4 UUID that leaves 122 random bits. You can read the version straight off the string: the first digit of the third group is the version number, so a UUID reading 3f2a91c4-8b0e-4d17-9f3a-6c1de52b7a90 is version 4, and the 9 that starts the fourth group marks the standard variant. Everything else in that string is randomness.
Choosing a version, in practice
Version 4 is random and is the correct default when you just need a unique value with no structure. Version 1 and version 6 embed a timestamp and a node identifier, historically the MAC address, which leaks information about the machine and the moment of creation. Version 3 and version 5 are deterministic hashes of a namespace plus a name, so the same input always produces the same UUID; version 5 uses SHA-1 and is preferred over the MD5-based version 3. Version 7 embeds a Unix millisecond timestamp in the leading bits and fills the rest with randomness. If you are storing identifiers in a database index, version 7 is usually the better default.
Why version 7 sorts, and why that matters
Random identifiers scatter. When version 4 UUIDs are used as a primary key, each insert lands at an arbitrary point in the B-tree, so the database repeatedly splits pages and dirties blocks all over the index instead of appending at the end. On a large table this shows up as write amplification and a shrinking buffer-cache hit rate. Version 7 puts 48 bits of millisecond timestamp first, so newly generated values sort after older ones and inserts stay near the right edge of the index. You keep global uniqueness without coordinating a sequence, and you get back the insert locality that an auto-increment key gives you for free.
Collision probability, with real numbers
With 122 random bits there are roughly 5.3 x 10^36 possible version 4 values. The birthday bound says you reach a 50 percent chance of one collision after about 2.7 x 10^18 UUIDs, which is on the order of a billion values every second for 85 years. At a more realistic scale — a trillion UUIDs, far more than most systems will ever mint — the probability of any collision is still around one in ten million. The practical conclusion is that a correctly generated version 4 UUID does not need a uniqueness check. The real risk is not the math but a weak random source: an identifier generated from Math.random(), a seeded PRNG, or a poorly initialised embedded device can repeat even though the format looks fine.
Storage, formatting and comparison
The canonical text form is 36 characters, 32 hex digits plus four hyphens, and is conventionally lowercase, though parsers should accept uppercase. The underlying value is only 16 bytes, so a native UUID column in PostgreSQL or a BINARY(16) in MySQL uses well under half the space of a CHAR(36) and compares faster. Some systems add a urn:uuid: prefix or wrap the value in braces; both are the same 128 bits. Because case and hyphenation vary between sources, normalise on the way in rather than comparing raw strings — otherwise the same identifier arriving from two services can look like two different records.
When a UUID is the wrong tool
A UUID is an identifier, not a secret. Version 4 is unguessable in practice, but treating it as a capability token means anyone who sees a URL, a log line, or a Referer header holds the key, and it never expires. Use a real token with a scope and an expiry instead. Version 1 and version 6 are worse for anything public because the embedded timestamp and node identifier disclose when and where the value was created. UUIDs are also poor user-facing identifiers: nobody reads a 36-character string over the phone, so an order number or short code usually serves people better while the UUID stays internal.