UUID Collisions: UUID v4 Collision Probability Math
The uuid v4 collision probability is not zero, but it is close enough to zero for any real system to treat it that way. A version 4 UUID packs 122 random bits, giving a space of about 5.3 times 10^36 possible values. Using the birthday bound, the point where you have roughly a 50 percent chance of seeing just one collision is around 2.71 quintillion (2.71 x 10^18) randomly generated UUIDs. That is not 2.71 quintillion per second, it is 2.71 quintillion total, ever, across every UUID your systems have ever produced. Most applications generate somewhere between thousands and low billions of UUIDs over their entire lifetime, several orders of magnitude short of that threshold, so the practical probability of a collision is effectively zero.
What a UUID v4 actually is, bit by bit
A UUID is 128 bits total, usually written as 32 hex characters split into five groups. Version 4, defined alongside the other UUID versions in RFC 4122, fills almost all of those bits with random data. Six bits are reserved to mark the version and variant, so you are left with 122 bits of actual randomness. That gives 2^122 possible values, which works out to roughly 5.3 x 10^36, a number with 37 digits.
Contrast that with UUID v1, which encodes a timestamp and a node identifier instead of pure randomness. v1 avoids collisions through structure rather than probability, but it leaks information about when and where an ID was generated, which is part of why v4 became the default choice for most application code that just needs a unique identifier.
The birthday problem, not simple division
The intuitive but wrong way to think about collisions is dividing 1 by the total space and assuming that is your risk per UUID generated. The right framework is the birthday problem: with n items drawn from a space of size N, the chance of at least one pair matching grows much faster than n divided by N, because every new item is checked against every item already generated, not just against a single target.
The standard approximation for the number of draws needed to reach a 50 percent chance of one collision is n is approximately equal to 1.1774 times the square root of N. Plugging in N equals 2^122 gives a square root of about 2.3 x 10^18, and multiplying by 1.1774 lands you at approximately 2.71 quintillion (2.71 x 10^18) UUIDs. That is the number worth remembering: generate 2.71 quintillion random v4 UUIDs and you cross the point where a collision becomes roughly a coin flip. Generate far fewer, and the odds drop off exponentially, not linearly.
Putting 2.71 quintillion in perspective
Ten quintillion is a number most engineers never encounter in a running system. If every person on Earth generated a billion UUIDs a day, it would take roughly a thousand years to reach 2.71 quintillion total. A busy distributed system logging one million events per second would need to run continuously for around 86 thousand years to hit that count. A scientific calculator makes it easy to check this kind of exponent arithmetic yourself if you want to plug in your own generation rate and see how far off you are from the threshold.
This is why the common claim that UUID v4 collisions are practically impossible holds up mathematically rather than being just a reassuring slogan. The math describes a threshold so far beyond realistic usage that treating the probability as zero in application design is a reasonable engineering decision, not an approximation people are hoping is close enough.
Where the uuid v4 collision probability actually starts to matter
The math changes if your random number generator is not actually random. A weak or predictable pseudo random source shrinks the effective entropy well below 122 bits, and a system reusing seeds or drawing from a narrow range can produce collisions far sooner than the theoretical bound suggests. This is a real failure mode in poorly configured environments, embedded systems with weak entropy sources, or code that accidentally seeds a random generator with a fixed value. The risk in practice usually comes from implementation bugs, not from the size of the UUID space itself.
It also matters if you are combining UUIDs from many independent sources at extreme scale, such as billions of devices each generating IDs continuously for years. Even then, the numbers above suggest you would need an enormous, sustained global generation rate to approach real risk, and most organizations are nowhere close. If you want to sanity check a specific scenario, a probability calculator lets you work through the birthday bound with your own generation volume rather than relying on the generic example above.
For anyone building identifier schemes and comparing options, it is worth remembering that UUIDs are one tool among several for generating unique values. A hash generator is useful when you need a deterministic identifier derived from existing content instead of a random one, and a statistics calculator can help if you are modeling collision risk across a distribution of generation rates rather than a single fixed number. Between random UUIDs, deterministic hashes, and database sequence numbers, the right choice depends on whether you need randomness, determinism, or ordering, not just uniqueness.
Why this math still gets questioned
Large numbers are hard to reason about intuitively, so it is natural to be skeptical of a claim like effectively zero. But the birthday bound is not a heuristic, it is a direct consequence of how combinatorics work when you are checking every new draw against every prior draw in a fixed size space. Once you work through the square root relationship and see that 2.71 quintillion is the actual midpoint of the probability curve, the practical guidance follows directly from the arithmetic rather than from intuition or reputation.
Generate real UUIDs and run the numbers yourself
Reading the math is one thing, seeing it applied is another. Use the free UUID Generator to produce actual version 4 identifiers on demand, then take the birthday bound formula to the Probability Calculator to test collision odds at whatever generation volume matters for your own system, whether that is a thousand IDs a day or a billion.
Open the UUID Generator Open the Probability CalculatorRelated tools for identifiers and math checks
If you are choosing between a random UUID and a content derived identifier, the hash generator above produces deterministic values you can compare against random ones for your use case. For working through the exponent arithmetic behind the birthday bound on your own numbers, the scientific calculator handles the square roots and large powers cleanly. And if you are modeling collision risk across a range of possible generation rates rather than one fixed figure, the statistics calculator can help summarize that distribution. Browse the rest of the tools directory for more utilities like these, or check the ConvertNow blog for related explainers.
The short version
UUID v4 uses 122 random bits, and the birthday bound puts a 50 percent chance of one collision at around 2.71 quintillion generated values, a number no realistic application comes close to reaching. The uuid v4 collision probability at normal application scale is effectively zero, provided the random number generator behind it is actually random. Treat weak entropy sources as the real risk to watch for, not the size of the UUID space itself.
FAQ: UUID Collisions: UUID v4 Collision Probability Math
What is the uuid v4 collision probability in simple terms?
It is the chance that two randomly generated version 4 UUIDs turn out identical. Using the birthday bound on the 122 bit random space, that chance reaches about 50 percent only after roughly 2.71 quintillion UUIDs have been generated, which is far beyond what any real application produces.
How many bits of randomness does a UUID v4 actually have?
128 bits total, minus 6 reserved for version and variant markers, leaving 122 bits of true randomness, which gives about 5.3 x 10^36 possible values.
Why is the birthday problem the right way to calculate this, not simple division?
Because every new UUID is compared against every previously generated one, not against a single fixed target. That means risk grows with the square of the count generated rather than linearly, which is why the safe threshold is the square root of the total space rather than a small fraction of it.
Is 2.71 quintillion UUIDs a realistic number for any application to reach?
No. Even a system generating one million UUIDs per second continuously would need about 86 thousand years to reach that count. Almost no real system operates anywhere near that volume.
Can UUID v4 collisions happen for reasons other than pure bad luck?
Yes. A weak or predictable random number generator, a reused seed, or a low entropy source in an embedded system can produce far more collisions than the theoretical math suggests, since the effective randomness is lower than 122 bits in those cases.
Is UUID v1 safer from collisions than UUID v4?
UUID v1 avoids collisions through structure, combining a timestamp with a node identifier, rather than through sheer randomness. It has different tradeoffs, including leaking generation time and machine information, which is why many systems prefer v4 despite its probability based guarantee.
Should I add my own uniqueness checks on top of UUID v4?
For most applications this is unnecessary overhead given how far realistic usage sits from the collision threshold. It can make sense in extremely high volume, long lived systems, or when you cannot verify the quality of the random number generator being used.
How can I test collision odds for my own UUID generation volume?
Use the birthday bound formula, n approximately equal to 1.1774 times the square root of the total space, with a probability calculator to plug in your own expected count and see how close you sit to the 50 percent threshold.