UUIDs show up everywhere in modern software — database primary keys, API request IDs, file names, session tokens — usually accompanied by a vague sense that they're "random enough" to never collide with each other. That confidence is generally well-placed, but understanding why it's well-placed, and which specific UUID version actually provides that guarantee, is worth knowing before you assume every UUID-shaped string carries the same properties.
What a UUID actually is
A UUID (Universally Unique Identifier) is a 128-bit value, conventionally displayed as 32 hexadecimal characters split into five groups by hyphens. That's the entire structural definition — the interesting part is how those 128 bits get generated, because different UUID "versions" fill those bits using genuinely different strategies, and the strategy used determines what properties the resulting identifier actually has.
Version 4: the one almost everyone actually means
When people casually say "just generate a UUID" without specifying a version, they almost always mean version 4, which is by far the most commonly used variant in everyday software. Version 4 UUIDs are generated using (ideally) a cryptographically strong random number generator, with a small number of fixed bits reserved to identify the UUID's version, and the remaining bits filled with genuine randomness.
The uniqueness guarantee for version 4 isn't an absolute mathematical certainty — it's a probabilistic one, resting on the sheer size of the space of possible values. With 128 bits and the version and variant bits fixed, there are still an astronomically large number of possible random combinations, large enough that the probability of two independently generated version 4 UUIDs colliding is negligible for any practical purpose, even at a scale of generating billions of them. It's not literally impossible in a strict mathematical sense, but the probability is low enough that it's treated as effectively impossible in virtually every real-world engineering context.
Older versions used different, non-random strategies
Version 1 UUIDs, an older approach, are generated from a combination of the current timestamp and the network hardware address (MAC address) of the generating machine, rather than pure randomness. This guarantees uniqueness through a completely different mechanism — no two devices should share the same MAC address, and no single device should generate two version 1 UUIDs at the exact same timestamp — but it has a notable downside: embedding a device's MAC address inside a supposedly opaque identifier can leak information about which physical machine generated a given UUID, which is a real privacy and security consideration in some contexts that version 4's pure randomness doesn't carry.
Versions 3 and 5 take a different approach still, generating a UUID deterministically from a hash of a namespace and a name, meaning the same input always produces the exact same UUID output — genuinely useful for a specific use case (generating a consistent, reproducible identifier for the same logical entity every time) but the opposite of what most people actually want when they reach for a UUID expecting a fresh, unpredictable value.
Why version matters for security, not just uniqueness
If a UUID is ever being used in a context where unpredictability actually matters for security — a password reset token, a session identifier, anything where an attacker guessing the value would be a genuine problem — the specific generation method matters enormously, not just the fact that the result happens to be UUID-shaped. A version 4 UUID generated with a cryptographically secure random source is appropriately unpredictable for this kind of use. A version 1 UUID, with its timestamp-and-MAC-address structure, is far more predictable in principle, since an attacker with some knowledge of when and where it was likely generated has meaningfully more information to work with than pure randomness would ever hand them.
The quiet risk of a weak random number generator
Even for version 4 UUIDs specifically, the strength of the uniqueness and unpredictability guarantee ultimately depends on the quality of the random number generator actually used to fill those random bits. A cryptographically secure random source (the kind modern operating systems and most programming language standard libraries provide by default for UUID generation) gives you the strong guarantee described above. A weaker, non-cryptographic random number generator, if one somehow got substituted into the generation process, could produce UUIDs that look identical in format but carry meaningfully weaker actual randomness — a distinction that's invisible just by looking at the resulting string, since a version 4 UUID's structure doesn't reveal anything about the quality of randomness that produced it.
Practical takeaway
For the overwhelming majority of everyday use cases — database keys, general-purpose unique identifiers, request tracing IDs — version 4 UUIDs generated through a standard, well-maintained library are the right default and provide a genuinely strong uniqueness guarantee without needing to think much further about it. The cases that deserve more careful thought are specifically security-sensitive contexts, where the unpredictability (not just the uniqueness) of the identifier actually matters, and where it's worth explicitly confirming that whatever generation method is in use draws from a cryptographically secure random source rather than assuming any UUID-shaped value is automatically appropriate.
Generating one
Our UUID generator produces standard version 4 UUIDs using your browser's built-in cryptographically secure random number generation, appropriate for the general-purpose use case that covers the large majority of everyday UUID needs.