What Is a UUID and When Should You Use One

October 17, 2026 • NOFYI Editorial Team

You have probably seen a long string of letters and numbers like 550e8400-e29b-41d4-a716-446655440000 in a database, an API response, or a log file. That string is a UUID, short for Universally Unique Identifier. It is a standard way to give something an ID that is unlikely to collide with any other ID, even when different computers create IDs at the same time without talking to each other. UUIDs show up in user accounts, orders, files, devices, sessions, and distributed systems. This guide explains what a UUID is, how version 4 works, when you should use one, and when a simpler ID would be better.

What Is a UUID

A UUID is a 128-bit identifier, usually written as 32 hexadecimal characters grouped into five sections separated by hyphens. Hexadecimal means digits 0 to 9 and letters a to f. The standard text format is 8-4-4-4-12 characters. That means eight characters, then a hyphen, then four characters, then a hyphen, then four characters, then a hyphen, then four characters, then a hyphen, then twelve characters. A well-known example is 550e8400-e29b-41d4-a716-446655440000. You may see UUIDs in lowercase or uppercase. Lowercase is more common in modern systems, and most tools treat the two forms as the same value.

The format includes version and variant information. In a version 4 UUID, the first character of the third group is always 4. That 4 tells you the UUID was generated from random data. In the example 550e8400-e29b-41d4-a716-446655440000, the third group starts with 4. The first character of the fourth group is usually 8, 9, a, or b in a version 4 UUID. In the example, the fourth group starts with a. Those fixed bits are part of the standard. The rest of the characters are random. That structure makes it easy to recognize a version 4 UUID and to check that a string looks valid.

There are several UUID versions. Version 1 uses a timestamp and a machine identifier. Version 3 and version 5 are created by hashing a name and a namespace, so the same input always produces the same UUID. Version 4 uses random data, so each generation produces a different value. Version 7, a newer addition, uses a timestamp plus random data so IDs sort roughly by creation time. Version 4 is still the most common choice when you want a simple, unpredictable, globally unique ID without storing extra state.

Why UUIDs Are Useful

The main benefit of a UUID is that you can create it anywhere without asking a central database for the next number. A web server, a mobile app, a background job, or an offline device can each generate a UUID and be confident that it will not clash with IDs created elsewhere. That property matters in distributed systems, in systems that merge data from multiple sources, and in apps that need to create records before they can reach a server. A UUID also does not reveal how many records you have. A sequential ID like 1, 2, 3 tells an observer that your 100th user has ID 100. A UUID reveals nothing about order or count, which can be useful for privacy and security, although it is not a substitute for proper access control.

UUIDs are also stable across systems. If you move data from one database to another, merge two databases, or send data to a partner system, UUIDs travel well because they do not depend on a local counter. You can use the same UUID as a reference in logs, API calls, and support tickets, and everyone can look up the same record. That stability makes debugging easier, especially when one request touches several services.

How to Generate a UUID

Step 1: Choose version 4 unless you have a reason not to

For most apps, version 4 is the safe default. It is random, widely supported, and available in almost every programming language. Use version 7 if you need IDs that sort by time and your database benefits from time-ordered keys. Use version 5 only when you need the same input to produce the same UUID every time, for example when you want a stable ID for a known name.

Step 2: Use a trusted generator

Do not write your own random ID generator from a weak random source. Use the standard library or a well-tested package in your language. In Python, use the uuid module. In JavaScript, use crypto.randomUUID in modern environments. In Java, use UUID.randomUUID. In Go, use a maintained UUID package. In PHP, use a maintained library or the built-in functions available in your version. These tools use a secure random source and set the version and variant bits correctly.

Step 3: Store it as text or binary consistently

Store a UUID as a 36-character string, including hyphens, if simplicity matters. Store it as 16 bytes of binary if storage size and index performance matter and your database supports it. Pick one form for a given column and keep it consistent. Do not mix hyphenated text, unhyphenated text, and uppercase variants in the same column, because that makes lookups and comparisons harder.

Step 4: Validate before you trust input

When a UUID arrives from a user, an API client, or a file, validate its format before you use it in a query. Check that it has the right length, hyphens, and hexadecimal characters. Most libraries have a parser that returns an error for invalid input. Reject invalid values early rather than letting them reach the database.

UUIDs as Database Keys

UUIDs can be used as primary keys, but they come with trade-offs. A UUID primary key lets you create a record in one service and insert it in another without waiting for an auto-increment value. It also makes it easier to merge data and to expose IDs in URLs without revealing a count. The cost is size and index behaviour. A UUID is 16 bytes in binary form or 36 characters as text, which is larger than a 4-byte or 8-byte integer. Larger keys make indexes larger and can slow down inserts in very large tables, especially when IDs are random and inserts land all over the index.

A common pattern is to use an integer auto-increment key internally and a UUID as an external reference. The internal integer keeps the database fast and compact. The external UUID is what you show in APIs, URLs, and integrations. Another pattern is to use version 7 UUIDs as primary keys when time ordering helps. Version 7 IDs are still unique, but they sort roughly by creation time, which can reduce index fragmentation compared with fully random version 4 IDs. Choose the pattern that fits your scale. For a small or medium app, a UUID primary key is often fine. For a very large table with heavy writes, test the impact before committing.

When you use a UUID as a key, add a unique index or primary key constraint. Do not assume uniqueness from randomness alone. The database should enforce it. Also avoid using a UUID as a clustering key in a way that hurts range queries unless you have measured the effect. If you need to sort by creation time, store a separate created-at timestamp and index that column.

Worked Example: Orders Across Two Services

Imagine a small shop with a website and a mobile app. Both can create orders. If both use auto-increment IDs starting at 1, they will both create an order with ID 1, and merging the data will cause a conflict. If both generate version 4 UUIDs, each order gets a distinct ID. The website might create order 550e8400-e29b-41d4-a716-446655440000. The mobile app might create a different order with a different UUID. When the two sets of orders are merged into one database, there is no clash, because the IDs were created independently but are effectively unique. The shop can use the UUID in confirmation emails, receipts, and support tickets, and any service can look up the same order by that ID.

Now imagine the shop wants to let a customer track an order from a link. The link can include the UUID. Because the UUID is random, a stranger cannot guess the next order ID by adding one to a known ID. That does not mean the link is secret. Anyone who sees the link can open it. If order details are private, the app must still check that the viewer is allowed to see that order. A UUID is an identifier, not a password. Treat it like a reference number, not a credential.

What UUIDs Are Not For

Do not use a UUID as a password, API secret, or session token on its own. A version 4 UUID has about 122 bits of randomness, which sounds large, but security tokens need proper generation, storage, expiration, and revocation. A UUID does not expire, does not rotate, and is often stored in logs and databases where it can leak. Use a dedicated token system for secrets. Also do not use a UUID when you need a short, human-friendly code. A UUID is long and hard to read aloud or type. For a short code, use a separate short code and keep the UUID as the internal ID.

Do not use a UUID to prove that something is secret. If a UUID appears in a URL, assume it can be shared, bookmarked, and logged. If you need to protect a resource, add authentication and authorization. Do not rely on the randomness of the ID to keep it private. Similarly, do not use a UUID as a substitute for a proper encryption key. Keys need specific generation and management. A UUID is not a key format.

Collisions: Practically Impossible, Not Theoretically Impossible

A collision means two different records get the same UUID. With version 4, the number of possible values is so large that collisions are practically impossible in normal use. You would need to generate an enormous number of UUIDs before the chance of a collision became meaningful. That is why UUIDs are trusted for distributed systems. Practically impossible does not mean mathematically impossible. If you generate a huge number of UUIDs, or if your random source is broken, collisions become possible. That is why you should still use a unique constraint in the database and handle the rare duplicate error. Do not try to check for collisions by scanning all existing IDs before every insert. Let the database enforce uniqueness.

Limitations

UUIDs are long, hard to read, and hard to type. They take more storage than integers. Random UUIDs can hurt index performance in very large tables. They do not sort by creation time unless you use a time-ordered version. They do not carry meaning. An ID like 550e8400-e29b-41d4-a716-446655440000 tells you nothing about what it refers to. You still need other columns for dates, names, and status. UUIDs also do not solve authorization or privacy on their own. If you expose a UUID, you must still check permissions.

FAQ

What does a UUID look like? A UUID is 32 hexadecimal characters in five groups separated by hyphens, in the pattern 8-4-4-4-12. An example is 550e8400-e29b-41d4-a716-446655440000.

What is the difference between UUID v4 and v7? Version 4 is random and unpredictable. Version 7 combines a timestamp with random data, so IDs sort roughly by creation time while remaining unique. Use v4 for a simple random ID and v7 when time ordering helps your database.

Can two UUIDs be the same? In theory, yes, but in practice collisions are extremely unlikely when you use a proper random generator. Use a unique constraint in the database so a rare duplicate is caught and handled.

Should I use a UUID as a password or secret? No. A UUID is an identifier, not a credential. Use proper password and token systems with expiration, rotation, and revocation for secrets.

A UUID is a simple tool with a clear job: give something a unique ID without needing a central counter. Use version 4 when you need a random ID, store it consistently, validate input, and add a unique constraint. Use it for database keys and external references when the benefits outweigh the cost of a larger key. Do not use it for secrets, short codes, or access control. With those rules, UUIDs make distributed systems easier to build and easier to debug.