Answer: The UUID Generator produces your output instantly from the input you provide — everything runs in your browser, free, with no signup required.
Generate RFC 4122 compliant UUID v4 identifiers
A UUID (Universally Unique Identifier), also known as a GUID (Globally Unique Identifier), is a 128-bit number used to uniquely identify information in computer systems. UUIDs are standardized by RFC 4122 and are represented as 32 hexadecimal digits displayed in five groups separated by hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The total number of possible UUIDs is 2^128, which is approximately 3.4 × 10^38 — so large that the probability of generating a duplicate is effectively zero.
This generator creates UUID version 4 (random), which uses random or pseudo-random bits for all 122 variable bits. The version digit (M) is set to 4 and the variant bits (N) are set to 8, 9, a, or b. Version 4 is the most commonly used UUID version because it requires no coordination between systems and works on any machine.
A UUID looks like this: 550e8400-e29b-41d4-a716-446655440000
Generated from the current timestamp and the machine's MAC address. The concern with v1 is that it can reveal the MAC address and when the UUID was created. Not recommended for security-sensitive applications.
Generated from a namespace UUID and a name string using MD5 hashing. The same inputs always produce the same UUID, making it deterministic.
Uses random numbers for all variable bits. The probability of a collision is astronomically low — you'd need to generate over 2.71 quintillion UUIDs to have a 50% chance of a single duplicate. This makes v4 ideal for almost all use cases.
Same as v3 but uses SHA-1 hashing instead of MD5. Preferred over v3 for new applications.
RFC 9562, published in May 2024, formally obsoleted RFC 4122 and added three versions. The one worth knowing is v7: it leads with a millisecond Unix timestamp followed by random bits, so identifiers sort in creation order. Databases like that — random v4 values land scattered across a B-tree index, while v7 values append at the right edge. v6 is a reordered v1 (timestamp first, no MAC exposure by convention), and v8 is a vendor-defined escape hatch.
| Version | How it's built | Sorts by time? | Typical use |
|---|---|---|---|
| v1 | Timestamp + MAC address | Yes, roughly | Legacy systems; leaks creation time and host |
| v3 | MD5 hash of namespace + name | No | Deterministic IDs from a name |
| v4 | 122 random bits | No | The default everywhere (this generator) |
| v5 | SHA-1 hash of namespace + name | No | Same as v3, stronger hash |
| v6 | Reordered v1 (time first) | Yes | Drop-in fix for v1 systems |
| v7 | Millisecond timestamp + random | Yes | Database keys, event streams |
| v8 | Vendor-defined | Depends | Custom layouts, not interoperable |
A v4 UUID has 122 random bits — the version nibble and two variant bits are fixed. That's 2122, about 5.3 × 1036, possible values. The right way to reason about duplicates is the birthday bound: it's not "will this UUID match some specific UUID," it's "will any two in my pile match." Even so, the numbers stay absurd:
| UUIDs generated | Odds of any duplicate | For scale |
|---|---|---|
| 1 million | ~1 in 11,000,000,000,000,000,000,000,000 | A rounding error on a rounding error |
| 1 billion | ~1 in 10 quintillion | A busy system's yearly output, still nothing |
| 1 trillion | ~1 in 10 trillion | Large-scale system territory, still negligible |
| 2.71 quintillion | 50% | A billion per second, nonstop, for 86 years |
Notice the shape of that table: the odds grow with the square of how many you generate, which is why a trillion is a trillion times riskier than a million — and still nothing. In practice, when two systems do see the same UUID twice, it's almost never bad luck; it's a copy-paste, a reseeded PRNG, or a v1 collision on cloned virtual machines.
The canonical form is 36 characters: 32 hex digits with four hyphens (8-4-4-4-12). This generator also emits uppercase, braced, hyphenless, and URN forms because different systems swallow different flavors — Microsoft APIs often expect braces, plenty of URL contexts want the compact 32-character version, and the urn:uuid: prefix is the namespace-safe way to embed a UUID in XML or RDF. Pick one per system and normalize on the way in; mixed-case duplicates are the classic "two different IDs" bug that isn't.
In a database, the compact representation is 16 bytes as BINARY(16) or a native UUID type, versus 36 bytes for the string. The string is friendlier in logs and debugging, the binary is friendlier to indexes — and with v7 the index penalty of random keys mostly disappears too.
Same thing. UUID is the RFC name, GUID is Microsoft's name from its COM era. Both are 128-bit identifiers with the same format — 32 hex digits in five groups.
Theoretically yes, practically no. A v4 UUID carries 122 random bits, so you'd need to generate about 2.71 quintillion of them — a billion per second for 86 years — before the odds of any duplicate reach 50%. A billion generated UUIDs still carry roughly 1-in-10-quintillion collision odds.
Works well for distributed systems. Prevents enumeration and enables merging. Tradeoffs: 16 bytes vs 4 for an int, and random v4 values scatter across a B-tree index — which is exactly what UUID v7 fixes. Store them as a 16-byte binary type rather than the 36-character string when index size matters.
This generator uses crypto.getRandomValues(), a cryptographically strong source — not Math.random(). Six bits are fixed by the spec (version and variant), leaving 122 random bits. Not suitable as an encryption key by itself, but excellent for identifiers.
Yes — entirely browser-based using the Web Crypto API. No server calls, safe for sensitive applications.
v4 is fully random; v7 starts with a millisecond timestamp followed by random bits, so IDs sort in creation order. Databases index v7 efficiently because inserts append instead of scattering. v7 was standardized in RFC 9562 in May 2024 alongside v6 and v8.
Compact and fast: a 16-byte BINARY(16) column, or your database's native UUID type (PostgreSQL's uuid does this). Human-readable: the 36-character hyphenated string in CHAR(36), which is what logs and URLs want. Avoid case-insensitive-collation VARCHAR columns — uppercase and lowercase variants of the same UUID will look like different values.