A version-4 UUID looks like 32 random hex characters, but two of them never vary: the format is xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, where that fixed 4 marks the UUID as version 4 (randomly generated, as opposed to the other UUID versions based on timestamps or namespaces), and y is always one of 8, 9, a, or b — a marker called the variant bits. Every other position is genuinely random, which works out to 122 random bits out of the 128-bit total (36 characters including the 4 hyphens, 32 of them hex digits).
122 random bits is an enormous space — roughly 5.3 undecillion possible values (5.3 × 10³⁶). Using the same birthday-paradox math that estimates collision odds for things like hash functions, you'd need to generate around 2.71 quintillion UUIDs before there's even a 50% chance that any two of them ever match — a commonly cited estimate for version-4 UUID collision risk. Generating a billion UUIDs a second, every second, would still take over 85 years to reach that number. In practice, the actual risk in any real system comes from a broken random number generator, not from the math of the ID space itself, which is a large part of why this generator uses the browser's built-in cryptographic random source (crypto.randomUUID()) rather than a weaker pseudo-random fallback whenever it's available.
UUIDs (universally unique identifiers) are commonly used as unique IDs for database records, files, or objects where you need an identifier extremely unlikely to collide with any other.
For version 4 (random) UUIDs, the odds of a collision are astronomically small — you could generate billions per second for years without a meaningful chance of a duplicate.
It refers to how the UUID is generated — version 4 UUIDs are based on random numbers, the most common type for general-purpose unique IDs.