What Is UUID v4 and Where Does It Come From

October 17, 2026 • NOFYI Editorial Team

A Long String That Means Almost Nothing, Until It Does

If you have ever looked at a database, an API response, or a software log, you have probably seen a string like 550e8400-e29b-41d4-a716-446655440000. It is long, it is full of letters and numbers, and it looks random. That string is an example of a UUID, which stands for Universally Unique Identifier. In this guide, we focus on version 4, usually written as UUID v4. It is one of the most common ways software creates a unique label for a thing, whether that thing is a user account, an order, a file, a session, or a database row.

This guide explains what UUID v4 is, where it comes from, how to read its structure, and when to use it. You will learn the 8-4-4-4-12 layout, what the version nibble and variant bits mean, how to work through a real example, why UUID v4 values are random rather than sequential, and why you should not use them as passwords. The goal is not to turn you into a cryptography expert. It is to give you enough understanding to recognize a UUID v4, explain it to someone else, and avoid the most common mistakes.

What UUID Means

A UUID is an identifier designed to be unique across space and time, without requiring a central authority to hand out numbers. That is a strong claim, and it is worth unpacking. In a small program, you can keep track of uniqueness yourself. You can number users 1, 2, 3, and so on, and you know that each number is unique because you assigned it. In a large, distributed system, that simple approach breaks down. Multiple servers, multiple databases, and multiple teams may all create records at the same time. If they all use simple counting, they will collide. Two different users might both get the number 42.

A UUID solves this by making the identifier space so large that random selection is practically unique. A UUID has 128 bits. That means there are 2 to the power of 128 possible values, which is an enormous number. If you generate UUIDs at random, the chance that two of them collide is so small that for ordinary applications you can treat it as zero, even though it is not mathematically zero. This is why the word universally is in the name. The idea is that anyone, anywhere, can generate a UUID without asking a central registry, and it will still be unique in practice.

There are several versions of UUID, and they differ in how they get their uniqueness. Version 1 uses a timestamp and a machine identifier. Version 3 and version 5 use a name and a hash function. Version 4 uses random numbers. Version 7, a newer version, uses a timestamp plus randomness so that values are roughly sortable by creation time. This guide focuses on version 4 because it is the simplest to understand, the most widely used in many web applications, and the version most people mean when they say random UUID.

Where UUID v4 Comes From

The UUID format comes from a standards document called RFC 4122, which was later updated by RFC 9562. These documents define the layout, the version field, and the variant field so that different systems can generate and read UUIDs in the same way. The standard does not say that a UUID must be generated by one specific program. It says that if you follow the layout and the rules for the version and variant bits, your value will be recognized as a UUID by other systems.

UUID v4 gets its uniqueness from randomness. A proper UUID v4 generator uses a cryptographically secure random number generator to fill most of the 128 bits with random data, then it sets a few special bits to mark the value as version 4 and to mark the variant. Those special bits are not random. They are fixed markers that let anyone reading the UUID know which rules were used to create it. Everything else is random.

The phrase where does it come from can also be read more practically: where do you get a UUID v4 in real code? In most programming languages, there is a built-in library or a standard function. Python has a uuid module with uuid4. JavaScript in browsers has crypto.randomUUID. Java has UUID.randomUUID. Go has libraries for UUID generation. Databases such as PostgreSQL have functions like gen_random_uuid. You do not need to write your own generator, and in general you should not, because getting randomness right is harder than it looks. Use the standard library for your language or database.

How to Read a UUID v4: The 8-4-4-4-12 Layout

A UUID is written as 32 hexadecimal digits, grouped by hyphens into five groups with lengths 8, 4, 4, 4, and 12. Hexadecimal digits are 0 through 9 and a through f. That grouping is often written as 8-4-4-4-12. The hyphens are not part of the value itself. They are separators that make the string easier to read and copy. A UUID with hyphens has 36 characters in total: 32 hex digits plus 4 hyphens.

Here is the layout with the groups labeled: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The first group has 8 digits. The second group has 4 digits. The third group starts with M, which is the version nibble. The fourth group starts with N, which is the variant field. The fifth group has 12 digits. A nibble is 4 bits, which is exactly one hexadecimal digit. That is why the version can be read as a single character.

In a UUID v4, the version nibble M must be 4. That is the rule that marks the value as version 4. If you see a UUID where the first character of the third group is not 4, it is not a UUID v4. It might be another version, or it might be a value that only looks like a UUID. The version nibble is the fastest way to tell which version you are looking at.

The variant field N is the first character of the fourth group. In the standard UUID variant, N must be 8, 9, a, or b. Those four values correspond to the binary patterns 10xx, where the first two bits are 1 and 0. The variant tells readers which layout rules the UUID follows. The most common UUIDs you will see use this variant. Older or non-standard UUIDs can have other variant values, but for modern UUID v4 values, you should expect 8, 9, a, or b in that position.

Worked Example: 550e8400-e29b-41d4-a716-446655440000

Let us walk through the well-known example 550e8400-e29b-41d4-a716-446655440000 step by step. This example appears in the UUID standard itself, and it is useful because it shows every part clearly. It is not a secret or a password. It is a published example.

Step 1: Split the string into its five groups. Group one is 550e8400, which has 8 characters. Group two is e29b, which has 4 characters. Group three is 41d4, which has 4 characters. Group four is a716, which has 4 characters. Group five is 446655440000, which has 12 characters. Count them and you get 8-4-4-4-12, which matches the UUID layout.

Step 2: Check the version nibble. The third group is 41d4. Its first character is 4. That is the version nibble, and it equals 4, so this is a UUID v4. If the third group had started with 1, it would be version 1. If it had started with 7, it would be version 7. Here it starts with 4, so it is version 4.

Step 3: Check the variant. The fourth group is a716. Its first character is a. The allowed variant values for the standard variant are 8, 9, a, and b. Since a is in that set, the variant matches the standard layout. If the fourth group had started with c, d, e, or f, it would not match this variant, and you would know to treat it with suspicion.

Step 4: Check the total length. The string has 32 hex digits and 4 hyphens, for 36 characters total. The hex digits are all in the range 0 to 9 or a to f. There are no other letters, no spaces, and no missing hyphens. That is a well-formed UUID.

Step 5: Interpret what it means. This UUID does not encode a name, a date, or a counter. It does not tell you who created it or when it was created. It is a random label that happens to have the version and variant markers set correctly. Its meaning comes from how a system uses it, for example as the identifier for a user, an order, or a file. The UUID itself carries no information about that object beyond its uniqueness.

That last point is important. A UUID v4 is not a description. It does not contain the object it labels. It is more like a random serial number that a system assigns and then stores alongside the object. If you lose the database that maps UUIDs to objects, the UUID alone will not tell you what it referred to.

Random, Not Sequential

UUID v4 values are random, not sequential. That means each new UUID is independent of the previous one, and you cannot predict the next UUID from the current one. You also cannot sort UUID v4 values to get creation order. If you generate three UUID v4 values in a row, they will look unrelated, and sorting them alphabetically will not tell you which one was created first.

This randomness has both benefits and costs. The benefit is privacy and security in a limited sense. Because UUID v4 values are not sequential, an attacker cannot easily guess the next identifier by adding one to the current one. If user accounts were numbered 1001, 1002, 1003, an attacker could try 1004, 1005, and so on. With UUID v4 values, that simple guessing does not work. The attacker would have to guess a 122-bit random value, which is not practical.

The cost is that UUID v4 values are not friendly for database indexing or for human use. Databases often store rows in order, and sequential identifiers make it easy to find recent rows and to keep the index compact. Random UUIDs scatter new rows across the index, which can make inserts slower and the index larger. They are also hard to read aloud, hard to type correctly, and hard to remember. That is why many systems use a sequential integer for internal ordering and a UUID for external references, or they use UUID version 7, which is designed to be roughly sortable by time.

Another cost is debugging. When you look at logs, sequential identifiers make it easy to see that one event came after another. Random UUIDs do not give you that ordering. You need timestamps or sequence numbers alongside them if ordering matters. Do not rely on UUID v4 values to tell you which record is newer.

When to Use UUID v4

Use UUID v4 when you need a unique identifier that can be generated in many places without coordination, and when you do not need ordering or human readability. Common uses include identifiers for database rows in distributed systems, identifiers for API resources, correlation identifiers that tie together log entries for a single request, identifiers for files or uploads, and identifiers for sessions or temporary objects.

For example, if a web application runs on several servers and each server creates orders, using UUID v4 for order identifiers means the servers do not need to ask a central service for the next number. Each server can generate a UUID locally, and collisions are practically impossible. Similarly, if a mobile app creates a draft offline and later syncs it to a server, a UUID created offline will still be unique when it arrives.

UUID v4 is also useful as an external identifier. If you expose an identifier in a URL or an API, a UUID is less revealing than a sequential integer. It does not tell a user how many records you have, or whether their account was created early or late. That is a small privacy benefit, but it is not a security control on its own. You still need authentication and authorization to protect resources.

When Not to Use UUID v4

Do not use UUID v4 when you need a value that can be sorted by creation time. Use a timestamp, a sequential identifier, or UUID version 7 instead. Do not use it when you need a short, human-friendly code, such as a confirmation code that a person will type. A six-digit code or a short alphanumeric code is better for that purpose, even though it has a smaller space.

Do not use UUID v4 as a password, a secret, or an authentication token on its own. This is a critical limitation. A UUID v4 is unique, but uniqueness is not the same as secrecy or security. A UUID v4 has about 122 bits of randomness, which is a large space, but it is still a predictable format, and it is often stored in logs, URLs, and databases where it can leak. Passwords should be chosen by users or generated by a password manager with the right length and character set, and they should be hashed. Secrets and tokens should be generated with a dedicated secure random generator and handled with the appropriate storage and rotation rules. Treating a UUID as a secret because it looks random is a common mistake.

Similarly, do not use a UUID v4 as an encryption key. Encryption keys have specific length and generation requirements, and they should be generated with a cryptographic key generator, not with a general UUID function. A UUID might look like a key, but looking like a key is not the same as being a safe key.

Finally, do not assume that a UUID v4 is globally unique in the mathematical sense. It is practically unique because the space is enormous and the generator is random, but collisions are theoretically possible. For almost every application, the risk is negligible. For safety-critical or cryptographic applications, you need stronger guarantees and a different design.

How to Generate a UUID v4 Safely

Use your platform’s standard library. In Python, use the uuid module. In JavaScript, use crypto.randomUUID in modern browsers and runtimes. In Java, use UUID.randomUUID. In a database, use a built-in function such as gen_random_uuid in PostgreSQL. These functions use a secure random source and set the version and variant bits correctly. Avoid copying a UUID generator from a random blog post or writing your own with Math.random or a similar non-cryptographic source. Non-cryptographic randomness can be predictable, which defeats the purpose of a random UUID.

When you store a UUID, store it as a UUID type if your database supports it, or as a fixed-length string. Avoid storing it in a case-sensitive way that treats uppercase and lowercase as different values. UUIDs are usually shown in lowercase, but uppercase versions refer to the same value. Normalizing to lowercase when you store and compare UUIDs avoids duplicate-record bugs.

When you display a UUID, show the full 36-character form with hyphens, unless your API or system specifies a form without hyphens. Some systems strip hyphens for compactness, but the hyphens help humans verify the grouping and the version nibble. If you accept UUIDs as input, validate them. Check the length, the hyphen positions, the hex characters, the version nibble, and the variant. Reject values that do not match. Validation is cheap and prevents many bugs.

Frequently Asked Questions

What is UUID v4? UUID v4 is a version of the Universally Unique Identifier format that uses random numbers for most of its 128 bits. It is written as 32 hexadecimal digits grouped as 8-4-4-4-12, with the version nibble set to 4 and the variant field set to 8, 9, a, or b. It is designed to be practically unique without central coordination.

How do I read the example 550e8400-e29b-41d4-a716-446655440000? Split it into 550e8400, e29b, 41d4, a716, and 446655440000. The third group starts with 4, so the version is 4. The fourth group starts with a, which is one of the allowed variant values 8, 9, a, and b. The rest of the digits are random. The UUID itself does not encode a name or date.

Are UUID v4 values sequential? No. UUID v4 values are random, not sequential. You cannot predict the next UUID from the current one, and you cannot sort them to get creation order. If you need ordering, use a timestamp, a sequential identifier, or UUID version 7, which is designed to be roughly time-ordered.

Can I use a UUID v4 as a password? No. Do not use a UUID v4 for passwords, secrets, or encryption keys. Uniqueness is not the same as secrecy. UUIDs often appear in logs and URLs, and they are not generated or stored with the same protections as passwords or keys. Use a password manager for passwords and a dedicated secure generator for secrets and keys.

UUID v4 is a simple idea with a powerful consequence: by choosing from an enormous space at random, software can create identifiers that are practically unique without asking permission. Learn to recognize the 8-4-4-4-12 layout, check the version nibble and variant, and remember that random does not mean sequential and unique does not mean secret. With those rules in mind, you can use UUID v4 correctly and explain it clearly to anyone who asks.