What Is a UUID? Versions, Format and When to Use v4

A UUID is a Universally Unique Identifier - a 128-bit value used as an ID without any central coordination. This guide explains what a UUID is, how to read the canonical 8-4-4-4-12 format, and what the different versions (v1, v3, v4, v5 and v7) actually mean. It focuses on version 4, the random variety used most often as a general-purpose identifier, and shows why two of them practically never collide. It also covers when a UUID is the right choice over a plain auto-increment integer, the trade-offs involved, and how to generate them in bulk for seeding databases or testing.

What is a UUID?

A UUID (Universally Unique Identifier, sometimes called a GUID on Microsoft platforms) is a 128-bit number designed to be unique across space and time. The key idea is that any machine can generate one independently and trust that it will not clash with a UUID generated anywhere else, without asking a central server or database for the next available value. That property makes UUIDs ideal as identifiers in distributed systems, where coordinating a single shared counter would be slow or impossible.

The UUID format

A UUID is written as 32 hexadecimal digits split into five groups in an 8-4-4-4-12 pattern, separated by four hyphens. Including those hyphens, the canonical text form is 36 characters long. Here is a concrete example:

• 550e8400-e29b-41d4-a716-446655440000
• Group sizes: 8 digits, then 4, then 4, then 4, then 12 hex digits
• Each hex digit encodes 4 bits, so 32 digits = 128 bits total
• Lowercase is conventional, but UUIDs are case-insensitive

Two positions inside the string carry meaning rather than data. The first hex digit of the third group (the 13th hex digit overall) is the version number. The first hex digit of the fourth group is the variant, which for the common layout is typically 8, 9, a, or b. In the example above, the 13th digit is 4 and the fourth group starts with a, so this is a version 4 UUID.

UUID versions

The version digit tells you how the UUID was generated. Each version has a different source of uniqueness:

• v1: based on a timestamp plus a node identifier, traditionally the machine's MAC address.
• v3: name-based, hashing a namespace and a name with MD5 to produce a deterministic UUID.
• v5: name-based like v3, but using SHA-1 instead of MD5.
• v4: random - almost all of the bits are filled from a random source.
• v7: a newer version that is ordered by Unix time, combining a timestamp prefix with random bits so the values sort by creation order.

The name-based versions (v3 and v5) are deterministic: the same namespace and name always produce the same UUID, which is handy for generating stable IDs from existing keys. If you want to experiment with the underlying digests those versions rely on, see the Hash Generator.

How version 4 works and why collisions are nearly impossible

A version 4 UUID is essentially random. After the version and variant bits are fixed in place, 122 bits remain and are filled from a random source. That leaves an enormous space of possible values. The chance that two independently generated v4 UUIDs happen to be identical is negligible for any realistic workload.

To put the scale in perspective: you would need to generate on the order of 2.71 quintillion v4 UUIDs before there was even a 50 percent chance of a single collision among them. For an application creating thousands or millions of IDs, the practical collision risk rounds to zero, which is why v4 is the default choice when you just need a unique identifier and do not care about ordering.

When to use a UUID

UUIDs shine wherever you cannot or do not want to rely on a central authority to hand out IDs. Common situations include:

• Distributed systems where multiple services or nodes each mint their own IDs.
• Primary keys generated on the client before a row is ever sent to the database.
• Merging datasets from separate sources without ID collisions between them.
• Public-facing identifiers in URLs or APIs that do not leak how many records exist, unlike sequential integers that reveal counts and order.

Trade-offs versus auto-increment integers

UUIDs are not free. Compared with a plain auto-increment integer, they cost more storage and can hurt database performance in specific ways:

• Size: a UUID is 16 bytes, larger than a typical 4- or 8-byte integer, which adds up across big tables and every index that references the key.
• Ordering: a v4 UUID is random, so it is not naturally sortable by creation time the way an incrementing integer is.
• Index locality: because new v4 values land in random positions, inserts cause more scattered index access rather than appending neatly at the end.

If creation-time ordering and index locality matter to you, a time-ordered version such as v7 narrows the gap while keeping the no-coordination benefit. For many applications, though, the simplicity and independence of v4 outweigh the costs.

How to generate UUIDs in bulk

When you need many IDs at once - for seeding a database, generating test fixtures, or filling a spreadsheet column - generating them one at a time is tedious. The Zenoply UUID Generator produces version 4 UUIDs in bulk, and it runs locally in your browser so the values never leave your machine.

1. Open the UUID Generator.
2. Enter how many UUIDs you want to create.
3. Generate the batch - each one is a fresh random v4 value.
4. Copy the list and paste it wherever you need the identifiers.

That covers what a UUID is, how to read its format, what the versions mean, and when v4 is the right tool. When you are ready to create some, head to the UUID Generator and produce as many v4 UUIDs as you need, instantly and privately in the browser.