What a UUID is and how it is laid out
A UUID (universally unique identifier) is a 128-bit number used to label records, files, sessions and messages without a central authority handing out numbers. It is normally written as 32 hexadecimal digits in five groups separated by hyphens, in the pattern 8-4-4-4-12, for 36 characters in all. The current specification is RFC 9562, published in May 2024, which replaced RFC 4122. Two positions carry meaning in every version. The first digit of the third group is theversion; the first digit of the fourth group holds the variant, and for standard UUIDs it is always 8, 9, a or b because the top two bits are 10. In xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, the 4 marks version 4 and y is one of 8, 9, a or b.
Version 4 sets those six bits and fills the other 122 bits with random data. Other versions build the value differently: version 1 uses a timestamp and a node identifier, versions 3 and 5 hash a namespace and a name (MD5 and SHA-1, so the same input always gives the same UUID), and version 7 begins with a Unix millisecond timestamp so values sort by creation time. Two special values exist too: the nil UUID, all zeros, and the max UUID, all ones.
How this tool generates version 4 UUIDs
The generator calls crypto.randomUUID(), the browser's built-in function, which returns a version 4 UUID built from a cryptographically secure random source. That function exists only in secure contexts (HTTPS or localhost). If it is missing, the tool falls back to crypto.getRandomValues(): it fills 16 bytes with random data, replaces the top four bits of byte 6 with 0100 to mark version 4, replaces the top two bits of byte 8 with 10 to mark the standard variant, and prints the bytes as hexadecimal in the 8-4-4-4-12 layout. Either way the randomness comes from the operating system's secure generator and not from Math.random(), which is predictable and unsuitable for identifiers that must resist guessing. The count, case, hyphen and brace options only change how the finished string is written.
Collision probability, calculated and not promised
With b random bits, the chance that any two of n generated values coincide follows the birthday-problem approximation p ≈ n² / (2 · 2b), valid while p is small. For version 4, b = 122 and 2122 is about 5.3 × 10³⁶.
| UUIDs generated (n) | Chance of any duplicate (p) |
|---|---|
| 1,000,000 | 9.4 × 10⁻²⁶ |
| 1,000,000,000 | 9.4 × 10⁻²⁰ |
| 1,000,000,000,000 | 9.4 × 10⁻¹⁴ |
| 1,000,000,000,000,000 | 9.4 × 10⁻⁸ |
A billion UUIDs gives a duplicate chance on the order of 9.4 × 10⁻²⁰. To reach even odds you would need about 2.7 × 10¹⁸ values, which at a billion per second takes roughly 86 years. Keeping the risk at one in a billion allows about 1.0 × 10¹⁴ values. These figures assume the random source is uniform and unpredictable. That assumption, not the arithmetic, is where real-world duplicates come from: a weak generator, a virtual machine cloned with the same state, or a bug that reuses a value will produce collisions far sooner. For that reason a database should still enforce a UNIQUE constraint on any column that stores IDs generated by clients.
Using UUIDs as database keys
Random version 4 values are convenient because any server or client can mint them without coordination. The cost appears in ordered indexes. Most databases keep a primary key in a B-tree, and a random key lands in a random leaf, so inserts touch scattered pages, split them and keep a large part of the index hot in memory. Sequential keys instead append at the right edge. Time-ordered UUIDs such as version 7 address this, although they reveal the creation time and are not what this tool produces. Storage format matters too: the 36-character text form is 36 bytes, while the native uuid type or a 16-byte binary column is 16. At 1,000,000,000 rows the difference is 20 GB for each copy of the key, and secondary indexes in some engines copy the primary key. Use the native type where your database has one.
Worked examples
Reading a UUID. Take f47ac10b-58cc-4372-a567-0e02b2c3d479. The third group starts with 4, so it is version 4. The fourth group starts with a, which is 1010 in binary; the top two bits are 10, so it is the standard variant. Paste it into the inspector above to confirm. That leaves 128 − 4 − 2 = 122 bits of randomness.
Token strength. A hex token of n bytes has 8n bits and 2n characters. Sixteen bytes gives 32 characters and 128 bits; thirty-two bytes gives 64 characters and 256 bits. A 16-byte token therefore has a slightly larger search space than a version 4 UUID (128 bits against 122), and it is not tied to a fixed format.
Storage. One billion rows stored as 36-byte text instead of 16-byte binary cost 20 extra bytes each, which is 20 GB for the key column alone before any index overhead.
Common mistakes and misconceptions
- Treating a UUID as a secret. A UUID identifies something; it does not prove who is asking. If access control depends on nobody knowing the ID, a leaked link opens the data. Check permissions on the server.
- Using a UUID as a password reset or session token. Use a dedicated random token of at least 16 bytes, preferably 32, and store only a hash of it.
- Comparing case-sensitively. The standard says to output lower case and accept either case on input. Normalise before comparing or storing.
- Storing it as a number. 128 bits do not fit in a JavaScript number or a 64-bit integer. Keep it as a string or binary.
- Trusting client-supplied IDs. Anyone can send a chosen value. Validate the format and enforce uniqueness on the server.
- Confusing GUID with UUID. GUID is the Microsoft name for the same 128-bit identifier. Be careful with byte order when exchanging raw bytes between systems, since some store the first three fields little-endian.
When to use a random hex token instead
Choose a hex token when the value must be unguessable: API keys, session identifiers, invitation links and CSRF tokens. The generator draws bytes with crypto.getRandomValues() and writes each as two hexadecimal characters. Show the token to the user once and store a hash of it. If you need a hash for that, the hash generator can demonstrate the digest. For a password a person will type, use thepassword generator. To test a pattern that validates UUIDs, try the regex testerwith an expression such as ^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$ with the case-insensitive flag.
Limits of this tool
It creates version 4 identifiers only, so it cannot produce name-based or time-ordered values. The inspector reads the version and variant bits and reports what they say; it cannot tell you where a UUID came from. Nothing is stored or sent, and every click produces a fresh batch. Treat the output as identifiers, not as proof of authenticity.
Frequently Asked Questions
Are the generated values stored or sent anywhere?
No. They are created in your browser with the Web Crypto API and are not transmitted or saved. Reloading the page produces different values.
Can two UUIDs ever be the same?
In theory yes, in practice almost never. With 122 random bits, a billion version 4 UUIDs have a duplicate chance of about 9.4 × 10⁻²⁰ by the approximation above. Real risk comes from a poor random source, not from the size of the space, so keep a unique constraint where it matters.
What is the difference between UUID and GUID?
They are the same 128-bit format. GUID is the term used in Microsoft environments. Mind byte order only when you exchange raw bytes rather than text.
Does removing hyphens or changing case change the UUID?
No. The 32 hexadecimal digits are the value; hyphens and braces are decoration, and upper or lower case means the same thing. Pick one stored form and normalise to it so comparisons work.
Should I use a UUID or a hex token for an API key?
A hex token. A UUID is designed to be unique, not secret, and its fixed format and fewer random bits give an attacker less to guess than a 32-byte token does. Use UUIDs to name things and tokens to authenticate.
Related tools
- Hash generator - SHA digests for storing tokens
- Password generator - strong passwords for people to type
- Random number generator - random numbers in a range
- Regex tester - validate UUID patterns