UUID Generator

What a UUID is

A universally unique identifier is a 128-bit value written as 32 hexadecimal digits in five hyphen-separated groups. Its purpose is to let independent systems create identifiers that will not collide without any central coordination — no sequence server, no locking, no negotiation.

This generator produces version 4 UUIDs, which are random. Of the 128 bits, 6 are fixed to identify the version and variant, leaving 122 bits of randomness.

Are collisions realistic?

No, provided the randomness is good. There are 2^122 possible v4 UUIDs, roughly 5.3 x 10^36. To reach a 50% chance of a single collision you would need to generate about 2.7 x 10^18 of them. Generating a billion UUIDs per second, that is on the order of 85 years — and even then the probability of any given pair colliding remains vanishingly small.

The practical risk is not the mathematics but the source of randomness. This tool uses the browser's crypto.getRandomValues(), a cryptographically secure generator. Implementations built on Math.random() are not secure, may have far less entropy than advertised, and have produced real collisions in the wild.

The versions

Version 4 is the right default when you simply need a unique identifier. Versions 3 and 5 are useful when the same input must always produce the same identifier — deriving a stable ID from a URL, for instance. Version 7, standardised in 2024, is worth knowing about: it puts a millisecond timestamp in the high bits so the values sort chronologically, which solves the database problem described below.

UUIDs as database keys

Using v4 UUIDs as primary keys has a real cost that is easy to miss until a table grows large.

• Index fragmentation. Because v4 values are random, each insert lands at an arbitrary point in a B-tree index rather than appending at the end. This causes page splits and poor cache locality, and on write-heavy tables the difference against a sequential key is substantial.
• Storage. 16 bytes against 4 or 8 for an integer, multiplied across every secondary index that references the key.
• Readability. Nobody can read a UUID over the phone or spot a transcription error in one.

The advantages are equally real: identifiers can be generated client-side before an insert, merging data from separate systems needs no remapping, and sequential integers do not leak how many records exist or let anyone enumerate them. If you need both, use v7, or store the UUID as a native 16-byte type rather than a 36-character string — the latter nearly doubles the storage and slows every comparison.

Reading the format

In a valid v4 UUID the 13th hex digit is always 4, marking the version, and the 17th is one of 8, 9, a or b, marking the RFC 4122 variant. In the example above, the 4 in 4372 and the a in a567 are those markers. It is a quick way to sanity-check that a string is a genuine v4 UUID rather than arbitrary hex.

UUIDs are case-insensitive; lowercase is conventional. The hyphens are part of the canonical form but some systems store the 32 digits without them, and a few wrap the whole thing in braces.

Not secret, not a token

A UUID is an identifier, not a credential. A v4 UUID is unguessable in practice, which sometimes tempts people to use one as a password reset token or an unauthenticated access link. That is workable only if the value is generated from a secure random source, transmitted over HTTPS, given a short expiry and invalidated after use. Versions 1, 3, 5 and 7 are all partly predictable and must never be used this way.

Frequently asked questions