A UUID (Universally Unique Identifier) is designed to provide a practically unique identifier without requiring a central system to assign every value.

A typical UUID looks like this:

550e8400-e29b-41d4-a716-446655440000

With 128 bits available in the UUID format, there is an enormous number of possible values.

But this raises an important question:

Can two UUIDs ever be the same?

The short answer is yes, a collision is theoretically possible.

However, for properly generated UUIDs, the probability of an accidental collision is extremely small.

Understanding why requires looking at how UUIDs are generated and how the mathematics of collisions works.

What Is a UUID Collision?

A UUID collision happens when two independently generated UUIDs have exactly the same value.

For example, imagine two applications generate:

Application A:
550e8400-e29b-41d4-a716-446655440000

Application B:
550e8400-e29b-41d4-a716-446655440000

These two UUIDs are identical.

That is a collision.

In a properly implemented UUID system, accidental collisions should be extraordinarily unlikely. The exact risk depends on the UUID version and the quality of the generation method.

How Many Possible UUIDs Are There?

A UUID contains 128 bits.

If every bit could independently represent either 0 or 1, there would be:

2^128

possible combinations.

That is approximately:

340,282,366,920,938,463,463,374,607,431,768,211,456

possible 128-bit values.

That's an enormous number.

However, not all 128 bits are freely available for arbitrary data in every UUID version. Some bits are reserved for identifying the UUID version and variant.

For example, UUID v4 reserves specific bits for version and variant information, leaving 122 bits for random data.

That still provides:

2^122

possible random UUID v4 values.

Why Are UUID Collisions So Unlikely?

The key idea is the enormous size of the UUID space.

Suppose you randomly select one value from a very large collection.

The chance of selecting a particular existing value is extremely small.

Even after generating many UUIDs, the probability of accidentally generating a duplicate remains very low for a properly implemented UUID v4 generator.

But there is an important mathematical effect to understand.

It is called the Birthday Problem.

The Birthday Problem and UUIDs

The birthday problem is a famous probability problem.

There are only 365 possible birthdays in a simplified calendar model.

You might expect that you need hundreds of people before two people are likely to share a birthday.

In reality, with only 23 people, there is already a greater than 50% chance that at least two people share the same birthday.

Why?

Because you are comparing every person against every other person.

The same principle applies to UUID collisions.

You don't only compare the newest UUID against one previous UUID. You compare it against potentially millions or billions of previously generated UUIDs.

UUID Collision Probability

For a random identifier space containing N possible values, the approximate probability of at least one collision after generating k random identifiers is:

P ≈ 1 - e^(-k² / 2N)

When the probability is still small, this can be approximated as:

P ≈ k² / 2N

For UUID v4, the effective random space is approximately:

N = 2^122

So the collision probability grows approximately with the square of the number of generated UUIDs.

How Many UUIDs Can You Generate Before a Collision Becomes Likely?

For a UUID v4 space of 122 random bits, the 50% collision threshold is approximately:

2.7 × 10^18 UUIDs

That's roughly 2.7 quintillion UUIDs.

This doesn't mean that generating that many UUIDs guarantees a collision.

It means that under the ideal random model, the probability of at least one collision approaches 50% around that scale.

For normal applications, this number is far beyond typical UUID generation volumes.

Example: One Million UUIDs

Imagine generating:

1,000,000 UUIDs

Using a properly generated UUID v4, the probability of an accidental collision is extraordinarily small.

You can generate millions of UUIDs without realistically expecting a collision.

Example: One Billion UUIDs

Now imagine:

1,000,000,000 UUIDs

That's a billion identifiers.

Even at this scale, the probability of an accidental UUID v4 collision remains extremely small.

The important point is that the UUID space grows exponentially with the number of available bits.

Does UUID v4 Guarantee Uniqueness?

No.

UUID v4 does not mathematically guarantee that every generated value will be different.

It provides a huge random space that makes accidental collisions extremely unlikely when generated correctly.

There is an important difference between:

Guaranteed uniqueness

and

Practical uniqueness.

UUIDs are designed for practical uniqueness.

What About UUID v7?

UUID v7 is a modern UUID format that combines a timestamp with random data.

A UUID v7 contains a Unix timestamp in milliseconds along with additional bits for randomness and sequencing mechanisms.

This provides an important benefit:

UUID v7 identifiers can be naturally ordered by creation time.

However, UUID v7 does not mean collisions are impossible.

Its uniqueness still depends on the generation algorithm and the random or counter-based components used by the implementation.

So the general rule remains:

UUIDs are designed to make accidental collisions extremely unlikely, not mathematically impossible.

Can UUID Generators Produce Duplicate UUIDs?

A properly implemented UUID generator should produce identifiers according to the rules of the selected UUID version.

However, duplicate UUIDs can occur if the generator is poorly implemented.

Potential problems include:

Weak random number generation
Reusing the same random seed
Incorrect UUID implementation
Insufficient entropy
Broken libraries
Copying an existing UUID instead of generating a new one
Application-level bugs
Hardware or system-level randomness problems

This is why how a UUID is generated matters.

Why Cryptographically Secure Randomness Matters

For random UUID versions, the quality of the random source is important.

If a generator repeatedly produces predictable or identical random data, the theoretical UUID collision probability no longer describes the real-world behavior.

For security-sensitive applications, use an appropriate cryptographically secure random number generator (CSPRNG) rather than a basic predictable pseudo-random function.

This is especially important when identifiers might also be exposed to attackers.

Remember:

A UUID is primarily an identifier, not automatically a security token.

Do not assume that an ordinary UUID should be used as a password, authentication credential, or secret API token.

What Happens If Two UUIDs Collide?

The consequences depend on how the UUID is being used.

Consider a database where UUIDs are used as primary keys.

If two records receive the same UUID and the database enforces a unique constraint, the second insert may fail.

Without proper constraints, however, duplicate identifiers could cause serious application problems.

Possible consequences include:

Database insert failures
Incorrect record references
Overwritten data
Broken API resources
Incorrect relationships
Duplicate objects
Difficult-to-debug application errors

For this reason, applications should still enforce appropriate uniqueness constraints at the database or application layer.

Should You Check Every UUID for Duplicates?

For most applications, you don't need to maintain a massive global database of every UUID ever generated.

Instead, applications commonly enforce uniqueness where the UUID is used.

For example:

CREATE TABLE users (
    id UUID PRIMARY KEY,
    name TEXT
);

The primary key ensures that two records cannot have the same identifier.

This provides an additional layer of protection.

UUID Collision vs Duplicate UUID

These terms are sometimes confused.

UUID Collision

A collision occurs when independent generation processes produce the same UUID.

Example:

Generator A → abc123...
Generator B → abc123...

Duplicate UUID

A duplicate can also occur because the same UUID was intentionally reused, copied, imported, or inserted twice.

Therefore, not every duplicate UUID necessarily represents a random collision.

Are UUIDs Safer Than Sequential IDs?

UUIDs and sequential IDs solve somewhat different problems.

A sequential identifier might look like:

A UUID might look like:

6f9619ff-8b86-d011-b42d-00cf4fc964ff

Sequential IDs are simple and compact.

UUIDs have the advantage that different systems can generate identifiers independently without needing to coordinate a global sequence.

This makes UUIDs especially useful in:

Distributed systems
Microservices
APIs
Offline applications
Data synchronization
Multi-region applications
Event-driven architectures

UUID Collision Probability in Simple Terms

If the mathematics feels complicated, here's the practical explanation:

You can generate an enormous number of properly generated UUIDs before an accidental collision becomes a realistic concern.

For ordinary web applications, APIs, databases, and distributed systems, UUID collisions are generally not something developers need to worry about when using a correct implementation.

The bigger concern is usually implementation quality, not the UUID format itself.

How to Reduce UUID Collision Risk

You can reduce the risk by following a few simple practices.

1. Use a Standard UUID Library

Use a well-tested UUID implementation provided by your programming language or framework.

2. Use a Good Random Source

For random UUIDs, make sure your implementation uses an appropriate random source.

3. Don't Manually Construct UUIDs

Avoid writing your own UUID generation algorithm unless you have a specific reason and understand the standard.

4. Add Database Constraints

If UUIDs are database identifiers, use a primary key or unique constraint.

5. Choose the Appropriate UUID Version

Use UUID v4 when you need random identifiers.

Consider UUID v7 when time ordering is useful.

6. Validate UUIDs

If your application accepts UUIDs from external sources, validate their format before processing them.

How to Generate a UUID

You can generate UUIDs instantly with our free online UUID Generator.

For example, our tools support different UUID versions and bulk generation.

UUID Generator: /

UUID v4 Generator: /uuid-v4-generator

UUID v7 Generator: /uuid-v7-generator

Bulk UUID Generator: /bulk-uuid-generator

UUID Validator: /uuid-validator

These tools can be useful when testing applications, creating sample database records, or working with APIs.

Frequently Asked Questions

Can two UUIDs be the same?

Yes, it is theoretically possible for two UUIDs to be identical. However, properly generated UUIDs make accidental collisions extremely unlikely.

What is a UUID collision?

A UUID collision occurs when two independently generated UUIDs have exactly the same value.

What is the probability of a UUID v4 collision?

UUID v4 provides 122 random bits, resulting in an enormous possible value space. The collision probability remains extremely small for normal application workloads.

Are UUIDs 100% unique?

No finite identifier space can provide an absolute mathematical guarantee of uniqueness when values are generated independently. UUIDs provide practical uniqueness.

Can UUID v7 collide?

Yes, a UUID v7 collision is theoretically possible. Its design includes timestamp and additional data, but it is not an absolute guarantee of uniqueness.

How many UUIDs can be generated?

An enormous number of UUIDs can be generated. UUID v4 has approximately 2^122 possible random values.

Should UUIDs be database primary keys?

UUIDs can be used as database primary keys. Whether they are the best choice depends on the database, workload, indexing strategy, UUID version, and application architecture.

Are UUIDs secure?

UUIDs should primarily be considered identifiers. They should not automatically be treated as secure authentication tokens or passwords.

Does UUID v4 use randomness?

Yes. UUID v4 is based primarily on random or pseudorandom data, with specific bits reserved for version and variant information.

Is UUID v7 better than UUID v4?

Not universally. UUID v4 is useful for random identifiers, while UUID v7 is useful when time ordering is desirable.

Final Takeaway

Are UUIDs really unique?

They are practically unique, but not mathematically guaranteed to be unique.

The UUID format provides such a huge identifier space that accidental collisions are extraordinarily unlikely when UUIDs are generated correctly.

For UUID v4, 122 bits are available for random data, creating an enormous number of possible values.

The biggest risks are usually not the UUID standard itself but poor implementations, weak randomness, duplicated data, or application bugs.

For most applications, you can confidently use properly generated UUIDs without worrying about accidental collisions.

If you need a simple random identifier, UUID v4 is a popular choice. If you need time-ordered identifiers for modern applications, UUID v7 is worth considering.

Use a reliable UUID generator, validate external UUIDs, and enforce uniqueness where the UUID is stored.

Generate your next UUID with UUIDGenerator.info.

Are UUIDs Really Unique? Understanding UUID Collisions