If you are generating millions of identifiers for database records, payment transactions, or cloud microservices, one question inevitably crosses every software engineer’s mind:
“Are UUIDs actually 100% unique? What happens if two servers generate the exact same UUID at the same time?”
The short answer is: No, UUIDs are not mathematically guaranteed to be unique for eternity. However, for all practical software engineering purposes, the probability of an accidental collision is so astronomically small that it can be treated as virtually zero.
To understand why this is the case, we need to explore how probability works at massive scale, how the Birthday Paradox applies to 128-bit numbers, how UUID Version 4 and UUID Version 7 guarantee uniqueness, and what actually causes duplicate identifiers in real-world production environments.
1. What Is a UUID? (Quick Recap)
A UUID (Universally Unique Identifier) is a 128-bit (16-byte) number defined by the Internet Engineering Task Force (IETF) standard RFC 9562.
In text format, a UUID is written as a 36-character string made of 32 hexadecimal digits and 4 hyphens in an 8-4-4-4-12 grouping:
550e8400-e29b-41d4-a716-446655440000If you want to generate cryptographically secure identifiers right now, you can use our free browser-based UUID Generator.
2. What Is a UUID Collision?
A UUID collision occurs when a system generates an identifier that is identical to an identifier already created elsewhere:
Server A (Tokyo) ──► Generates: f47ac10b-58cc-4372-a567-0e02b2c3d479
Server B (New York) ──► Generates: f47ac10b-58cc-4372-a567-0e02b2c3d479 ◄── COLLISION!If a collision were to happen in a live production system, the consequences could include:
- Database Primary Key Violations: The database rejects the second record with a
Duplicate Keyerror. - Silent Data Overwrites: In databases without unique constraints (or key-value caches like Redis), record B might overwrite record A.
- Account Impersonation & Security Bugs: Two different users might be assigned the same internal identifier.
Because the stakes are high, understanding the mathematical probability of a collision is essential.
3. How Big Is the 128-Bit UUID Space?
A UUID contains 128 binary bits, which provides $2^{128}$ total theoretical combinations:
$$2^{128} = 340,282,366,920,938,463,463,374,607,431,768,211,456$$ (over 340 undecillion possible values).
However, not all 128 bits are available for randomness. Under RFC 9562, every standard UUID reserves:
- 4 bits for the UUID Version (e.g.,
4for random,7for time-ordered). - 2 bits for the UUID Variant (standard RFC layout).
For a random UUID v4, this leaves exactly 122 bits of pure cryptographic randomness:
$$2^{122} \approx 5,316,911,983,139,663,491,615,158,242,973,376,000$$ (approx. $5.3 \times 10^{36}$ possible combinations).
4. The Birthday Paradox: Why Human Intuition Fails
When people think about UUID collisions, they often imagine picking a single target UUID and asking: “What are the odds that the next UUID matches this specific one?”
The odds of matching one specific UUID are $1 \text{ in } 2^{122}$—an unimaginably small number.
However, in real systems, we are not asking if a new UUID matches one specific past ID. We are asking: “Do ANY TWO UUIDs in our entire database match each other?”
This is known in mathematics as the Birthday Paradox.
┌────────────────────────────────────────────────────────────────────────┐
│ The Birthday Paradox: │
│ In a room of just 23 people, there is a 50% chance that two share a │
│ birthday. Even though there are 365 days in a year, you are comparing │
│ every person against every other person (253 possible pairs). │
└────────────────────────────────────────────────────────────────────────┘When you generate $n$ UUIDs, the number of possible duplicate pairs grows quadratically:
$$\text{Pairs to check} = \frac{n(n - 1)}{2}$$
The approximate probability $p$ of a collision among $n$ randomly generated UUIDs drawn from an identifier space of size $N = 2^{122}$ is given by the formula:
$$p \approx \frac{n^2}{2N} = \frac{n^2}{2 \times 2^{122}} = \frac{n^2}{2^{123}}$$
5. How Many UUIDs Can You Generate Before a Collision?
Using the birthday-bound formula, we can calculate the exact statistical probability of encountering a collision across different scale thresholds:
| Total UUIDs Generated ($n$) | Collision Probability ($p$) | Odds of Collision |
|---|---|---|
| 1,000 | $9.4 \times 10^{-32}$ | 1 in $10^{31}$ |
| 1,000,000 (1 Million) | $9.4 \times 10^{-26}$ | 1 in $10^{25}$ |
| 1,000,000,000 (1 Billion) | $9.4 \times 10^{-20}$ | 1 in $10^{19}$ |
| 1,000,000,000,000 (1 Trillion) | $9.4 \times 10^{-14}$ | 1 in 10 trillion |
| 1,000,000,000,000,000 (1 Quadrillion) | $9.4 \times 10^{-8}$ | 1 in 10 million |
| 2.71 Quintillion ($2.71 \times 10^{18}$) | 0.50 (50%) | 1 in 2 (50% threshold) |
Putting the Numbers Into Perspective
To reach a 50% chance of a single collision:
- You would have to generate 1 billion UUIDs every second continuously for 85 consecutive years.
- The raw text storage for 2.71 quintillion UUIDs would require roughly 97 exabytes of disk space.
For any realistic software system generating millions or even billions of records per day, the probability of an accidental duplicate UUID v4 is virtually zero.
If you need to batch-generate thousands of test identifiers to verify uniqueness in your test suite, use our Bulk UUID Generator.
6. UUID v4 vs UUID v7 Uniqueness: How Do They Differ?
The new standard, RFC 9562, defines two primary versions used for modern applications: UUID v4 and UUID v7.
They achieve uniqueness through completely different architectural models:
┌────────────────────────────────────────────────────────────────────────┐
│ UUID v4: Global Random Uniqueness │
│ [ 122 bits of cryptographic randomness across all time and space ] │
├────────────────────────────────────────────────────────────────────────┤
│ UUID v7: Time-Partitioned Monotonic Uniqueness │
│ [ 48-bit Unix ms Timestamp ] + [ 74 bits of randomness / counter ] │
└────────────────────────────────────────────────────────────────────────┘1. UUID v4 Uniqueness Model
- UUID v4 spreads its 122 random bits across the entire universe of time and space.
- It does not care when an ID was created; uniqueness relies entirely on the quality of the system’s random number generator.
2. UUID v7 Uniqueness Model
- UUID v7 splits the 128 bits into a 48-bit millisecond Unix timestamp followed by 74 bits of randomness / sequence counter.
- Across Different Milliseconds: Collisions are mathematically impossible because the timestamp bits differ.
- Within the Same Millisecond: Uniqueness is guaranteed by 74 bits of cryptographic randomness ($1.88 \times 10^{22}$ combinations per millisecond) or an incrementing sequence counter.
Does UUID v7 Have a Lower Collision Risk Than v4?
Neither version is universally “more unique.”
- UUID v4 has a larger single random space (122 bits).
- UUID v7 partitions the collision domain into 1-millisecond slices, which prevents collisions across time while providing natural sorting for database B-Tree indexes.
7. Deterministic UUIDs: Are UUID v3 and v5 Unique?
UUID Version 3 (MD5) and UUID Version 5 (SHA-1) are name-based, deterministic UUIDs.
Unlike random v4 or time-based v7:
- If you generate a UUID v5 from the same namespace and string (e.g.,
"[email protected]"), it will always produce the exact same UUID. - This is not a collision; it is an intentional design feature allowing distributed microservices to calculate identical identifiers without querying a central database.
$$\text{Same Namespace} + \text{Same Name} \Longrightarrow \text{Identical UUID (By Design)}$$
8. What Actually Causes UUID Collisions in Real Life?
In practical production environments, when developers encounter a duplicate UUID, it is almost never caused by mathematical bad luck.
Real-world UUID duplicates are almost always caused by one of these four engineering bugs:
┌───────────────────────────────────┬───────────────────────────────────┐
│ Theoretical Collision Risk │ Real-World Engineering Failure │
│ 1 in 10,000,000,000,000,000,000 │ Common Developer & Runtime Bugs │
└───────────────────────────────────┴───────────────────────────────────┘1. Insecure Pseudorandom Number Generators (PRNGs)
Using weak random functions like Math.random() in JavaScript or rand() in PHP. These functions use predictable seeds with very small internal states, leading to repeat cycles. Always use cryptographically secure sources (crypto.randomUUID() or crypto.getRandomValues()).
2. Forked Processes and Virtual Machine Clones
If a Linux server forks worker processes (e.g., with Python’s multiprocessing or PHP-FPM) without re-seeding the PRNG, child processes may inherit the exact same random state and generate identical UUID sequences.
3. Faulty Custom Implementations
Attempting to implement a custom UUID string generator with simple string concatenation rather than adhering to RFC 9562 bit manipulation rules.
4. Cache & Copy-Paste Bugs
Frontend applications caching an ID and resending it on multiple API requests, or developers hardcoding a test UUID into database migration scripts.
9. Are UUIDs Safe for Database Primary Keys?
Yes, but you should ALWAYS enforce a database constraint.
Relying on the astronomical probability of UUID uniqueness does not excuse an engineer from defining database constraints.
-- Always declare primary key or unique constraints:
CREATE TABLE orders (
id UUID PRIMARY KEY, -- Enforces unique index at the database engine level
customer_id UUID NOT NULL,
total_amount NUMERIC(10, 2) NOT NULL
);Why Database Constraints Are Essential:
- Safety Net Against Application Bugs: If a frontend client accidentally retries a payload with the same ID, the database constraint cleanly rejects the duplicate instead of corrupting data.
- Index Optimization: Declaring a
PRIMARY KEYautomatically creates an underlying B-Tree index for high-speed lookups.
If you are using Microsoft SQL Server or Windows tools, identifiers are often called GUIDs. You can generate and format them with our GUID Generator.
10. How to Minimize UUID Collision Risks: Best Practices
To ensure maximum uniqueness in your applications, follow these golden rules:
- Use Established Standard Libraries: Use native platform methods like
crypto.randomUUID()in JavaScript,uuid.uuid4()in Python, orGuid.NewGuid()in .NET. - Use Cryptographically Secure Random Sources (CSPRNG): Ensure your runtime reads from the operating system’s entropy pool (
/dev/urandom,BCryptGenRandom, or Web Crypto). - Use UUID v7 for High-Throughput Databases: Combine time-ordering with monotonic counters for fast B-Tree indexing and guaranteed local uniqueness.
- Validate Incoming Identifiers: Check that incoming strings are structurally valid RFC UUIDs using our UUID / GUID Validator.
- Always Set
PRIMARY KEYorUNIQUEConstraints: Let your database enforce data integrity at the storage layer.
11. Alternative Encodings: Base64 UUIDs
While standard 36-character UUID strings are easy to read, they take up 36 bytes in JSON payloads.
By converting the raw 128-bit binary representation into URL-safe Base64, you can compress the identifier into just 22 characters while preserving 100% of its collision resistance:
Canonical UUID (36 chars): 550e8400-e29b-41d4-a716-446655440000
Base64 UUID (22 chars): VQ6EAOKbQdSnFkRmVUQAAATry our free Base64 UUID Generator to see how compact encoding works in practice.
12. Common Myths About UUID Uniqueness
Myth 1: “UUIDs are guaranteed to never collide.”
Fact: UUID uniqueness is probabilistic, not absolute. However, the probability of collision is so small ($1 \text{ in } 2^{122}$) that it can be treated as zero for practical engineering.
Myth 2: “UUID v7 has more collisions than UUID v4 because it has fewer random bits.”
Fact: UUID v7 isolates randomness to 1-millisecond windows. Across different milliseconds, IDs cannot collide because their timestamps differ. Within the same millisecond, 74 bits of entropy plus optional sequence counters guarantee uniqueness.
Myth 3: “A valid UUID is automatically globally unique.”
Fact: Format validation only checks that a string has 36 characters, correct hyphens, and valid hexadecimal digits. It does not prove whether someone else generated the same ID.
13. Frequently Asked Questions (FAQ)
Can two UUIDs be the same?
Theoretically yes, because 128 bits is a finite number of combinations. In practice, when using cryptographically secure random number generators, the chance of generating a duplicate is less than one in billions.
What is the probability of a UUID v4 collision?
For a database containing 1 billion UUID v4 records, the probability of a single collision is approximately $9.4 \times 10^{-20}$ (less than 1 in 10 quintillion).
Can UUID v7 collide?
UUID v7 identifiers generated in different milliseconds cannot collide because their leading 48-bit timestamps differ. Within the same millisecond, 74 bits of randomness or sub-millisecond sequence counters prevent collisions.
How many UUIDs can you generate before a 50% chance of collision?
For UUID v4, you must generate approximately 2.71 quintillion ($2.71 \times 10^{18}$) identifiers before reaching a 50% statistical probability of encountering a single duplicate pair.
What causes UUID collisions in production?
Real-world collisions are almost always caused by software bugs: using non-cryptographic PRNGs like Math.random(), unseeded forked processes, or hardcoded test values.
14. Conclusion & Developer Tools
UUIDs are not magic, but their enormous 128-bit mathematical space and standardized generation algorithms make them the most dependable decentralized identifier in computer science.
As long as you generate them using cryptographically secure entropy and enforce database unique constraints, you can use UUIDs with complete confidence.
Explore our full suite of free developer tools:
- UUID Generator — Create instant, cryptographically secure UUID v4 and v7 identifiers.
- GUID Generator — Generate Microsoft & .NET ready GUIDs.
- UUID / GUID Validator — Validate syntax, inspect version & variant data.
- Bulk UUID Generator — Generate up to 10,000 UUIDs in seconds.
- Base64 UUID Generator — Convert 128-bit UUIDs into compact 22-character strings.