What Is a UUID? v1 vs v4, How Uniqueness Works, and Collision Odds

Have you ever seen a long string separated by hyphens, like "550e8400-e29b-41d4-a716-446655440000," in an API response or a database record? That is a UUID. At first glance it looks like a random run of symbols, but it is actually a well-designed mechanism for creating an identifier that "does not collide no matter who creates it, when, or where in the world." This article explains, step by step, what a UUID is, what structure it has, and why it does not collide.

What Is a UUID

A UUID (Universally Unique Identifier) is a 128-bit value used in software to uniquely identify data or objects. It is sometimes called a GUID (Globally Unique Identifier), but they refer to essentially the same thing. The specification is standardized as RFC 4122, and many programming languages and databases include generation features out of the box.

The biggest feature of a UUID is that each device or program may generate one on its own, without asking a central issuing server. Even so, the chance that a generated value collides with another is kept negligibly small. In modern distributed systems where many servers and devices create identifiers in parallel, this property of being "unique without coordination" is enormously valuable.

To see what kind of values are generated, it is easiest to press the button a few times in the UUID Generator. You can feel how every press yields a completely different value, as many as you like.

Structure of a UUID: 128 Bits and Notation

A UUID is a 128-bit (16-byte) number. Because that is hard to handle as-is, it is usually converted to hexadecimal and written as a 36-character string with hyphens in an 8-4-4-4-12 digit layout.

550e8400-e29b-41d4-a716-446655440000

Without the hyphens it is a 32-digit hexadecimal number, corresponding to 128 bits. This string contains not only random bits but also a few regions that carry meaning.

• Version: the first digit of the third block indicates which method (version) created the UUID. In the example above it is "4," so this is a version 4 UUID.
• Variant: the first few digits of the fourth block indicate the UUID layout method (variant). Those following RFC 4122 usually begin with 8, 9, a, or b.

In other words, even though it looks like a random string, certain digits carry fixed meaning. The remaining bits are the body that provides uniqueness as an identifier.

The Difference Between v1 and v4

UUIDs come in several versions with different generation methods. The two commonly used in practice are v1 and v4.

v1 (time-based) is created by combining the generation time with node information that identifies the device (historically the MAC address of the network card). Because it includes the time, it is easy to give it a rough "when was it created" ordering. On the other hand, the originating device info and creation time can potentially be inferred from the UUID.

v4 (random-based) fills 122 bits with random numbers, except for the few bits that indicate version and variant. It needs no external information to generate, and it is hard to read the environment or time from the value, so it is the most widely used today. When people simply say "UUID," they often mean v4, and unless there is a special reason, choosing v4 is a safe default.

There are also v3 and v5, which are generated deterministically from a name, and the newer v7, which is sortable by time while still including randomness. Because the "sorts by time" property is useful for some purposes, v7 has been drawing attention in recent years.

Why It Does Not Collide: Uniqueness and Collision Odds

The reason a UUID can be unique without coordination is that the number of possible values is astronomically large. For v4, 122 bits are decided randomly, so the number of combinations reaches about 5.3×10^36. That far exceeds the number of grains of sand on Earth.

If you pick a value at random from this vast space, the probability of happening to draw the same value (a collision) becomes extremely small. Probability has a concept called the "birthday paradox," which says the chance of a matching value is higher than intuition suggests; even accounting for it, collisions essentially never happen at realistic scales. One way to put it: you would have to generate a billion UUIDs per second for about 85 years before even one collision might occur.

What matters here is that a UUID's uniqueness is not "guaranteed to never collide" but rather probabilistic uniqueness, meaning "the chance of a collision is negligibly small." That is exactly why using a high-quality random number generator is important.

• The uniqueness of v4 depends on the quality of the randomness. Using biased randomness raises the chance of a collision.
• v1 secures uniqueness through the combination of time and node info, so care is needed when generating large volumes at the same time on the same device.

To get a feel for "every value comes out completely different" by generating many at once, the UUID Generator makes it easy to issue values in bulk.

What It Is Used For: Primary Keys and Distributed IDs

The representative use of a UUID is any situation that needs an identifier (ID). It is especially powerful in the following cases.

1. Database primary keys

Using a UUID as the primary key that uniquely identifies a record lets the application decide the ID before creating the record. There is no need to wait for a serial number assigned at insertion, and even if multiple services or devices each generate IDs, they do not clash. This pairs particularly well with setups that split servers and distribute data (sharding).

2. Identifiers for distributed systems and public-facing IDs

In environments where many systems cooperate, like microservices, it is important that each system can issue IDs independently. With UUIDs, you do not need a central issuer, so coupling between systems can be kept loose. Also, using a UUID (especially v4) for an ID exposed externally in a URL or API makes it harder to guess the "next ID" or the total count, unlike a serial number.

How It Differs From Serial (Auto-Increment) IDs

Alongside UUIDs, a commonly used way to assign IDs is the serial (auto-increment) approach, the familiar 1, 2, 3… that increases in order. The two have clear strengths and weaknesses.

Serial IDs are short, easy for humans to read and write, and have order within the database, so index efficiency is good. On the other hand, since generation requires the database to assign numbers, distributing creation across multiple sites takes extra effort. Also, the ID reveals roughly "how many records in," so it can be unsuitable for public exposure.

UUIDs are the opposite: they can be generated anywhere and are hard to guess, but they are long and hard to read, and random v4 can hurt index locality and affect database performance. For this reason, intermediate options such as time-ordered v7, which can be "generated in a distributed way while still having order," have started to be used in recent years. It is not about which is superior; the right answer is to choose according to the system's requirements.

Thanks to its vast 128-bit space and probabilistic uniqueness, the UUID is a foundational technology that achieves identifiers that do not collide without coordination. Start by generating values in the UUID Generator, and confirm how a completely different string appears each time and where the version digit sits. Seeing and touching the mechanism is the shortcut to understanding.

Please note that this article is intended to provide general information. Which ID scheme to adopt in an actual system depends on performance, security, and operational requirements, and the best answer varies. Make your decision after checking the latest official specifications and documentation, and professional sources where needed.