Online GUID & UUID Generator

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier designed so that independently generated identifiers have an extremely low probability of accidentally colliding. A UUID is commonly represented as 32 hexadecimal characters divided into five groups, such as: 550e8400-e29b-41d4-a716-446655440000. The hyphens are part of the standard text representation, not the underlying 128-bit value.

UUIDs are commonly used to identify database records, objects, files, transactions, devices, and API resources. Unlike an auto-incrementing database ID, a UUID can be generated by an application without first contacting a central database for the next available number. UUIDs are particularly useful for distributed systems, while keeping the probability of an accidental collision extremely low.

UUID vs GUID

UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) generally refer to the same 128-bit identifier. GUID is Microsoft's long-standing term for this type of identifier, while UUID is the terminology used by modern standards. In .NET, System.Guid represents a UUID-compatible identifier. Today, the terms are commonly used interchangeably.

How Unique Is a UUID?

UUIDs are designed to make accidental collisions extremely unlikely when they are generated correctly.

A UUID contains 128 bits, but the number of bits available for application-specific or random data depends on the UUID version.

For UUID v4, 6 bits are reserved for the version and variant fields, leaving 122 random bits.

That provides:

2^122

possible random combinations, or approximately:

5.3 × 10^36

possible UUID v4 values.

It is not technically correct to say that UUIDs are guaranteed to be unique. The possibility of a collision always exists when values are generated from a finite set.

The important point is that the probability of an accidental collision with a properly generated UUID v4 is extraordinarily small for normal software applications.

The collision probability also depends on how many identifiers are generated. As the number of generated UUIDs increases, the probability of at least one collision increases according to the birthday problem. Even so, the available space of 122 random bits makes accidental UUID v4 collisions impractical to encounter in most real-world applications.

UUIDs Are Identifiers, Not Passwords

A UUID should generally be treated as an identifier, not as a security credential.

A properly generated UUID v4 contains a large amount of random data and is difficult to guess. However, an application should not depend on the difficulty of guessing a UUID as its only security mechanism.

For example, an API might use a UUID in a URL to identify a customer or document. The application should still authenticate the user and verify that the user is authorized to access that resource.

This distinction is important:

Uniqueness means independently generated identifiers are extremely unlikely to have the same value.

Unpredictability means that an attacker cannot practically predict or guess a valid value.

These properties are related but are not the same thing.

Some UUID versions also intentionally contain information about when or how an identifier was generated. UUID v1 contains time and node-related information, while UUID v7 contains a Unix timestamp. Applications should take these characteristics into account when deciding whether an identifier is appropriate for public URLs, APIs, or other externally visible data.

If an application needs a secret token, session token, password reset token, or other security credential, it should use a purpose-built cryptographic token rather than relying on a UUID.

UUIDs as Database Keys

UUIDs can be excellent database primary keys, but they are not automatically the best choice for every database or workload.

One major advantage is that an application can generate a UUID before inserting a record. The application does not need to obtain the next value from a central database sequence.

This can be useful in distributed systems, APIs, offline applications, data synchronization, and systems where multiple services create records independently.

There are also tradeoffs.

UUIDs are larger than typical integer keys, which means they require more storage and can make indexes larger. Their text representation is also less convenient for humans to read than a simple integer.

The ordering characteristics of the UUID version can matter as well. Random UUID v4 values do not have a natural chronological order. When used as keys in B-tree indexes, random insertion can result in less predictable index-page activity than sequential values.

UUID v7 addresses part of this issue by incorporating a timestamp into the identifier. UUID v7 values are generally ordered by creation time, making them useful when an application wants UUIDs while also benefiting from approximate chronological ordering.

This does not mean UUID v7 is always superior to an integer sequence. Database performance depends on the database engine, schema, indexes, workload, storage format, and access patterns.

The right choice should be based on the requirements of the application rather than on a general rule that UUIDs are always better or worse than integer keys.

UUID v7 Is a Modern UUID Standard

UUID v7 is a time-ordered UUID format defined by RFC 9562. It combines a Unix timestamp with randomly generated data, producing identifiers that are generally sortable by creation time while retaining the distributed-generation benefits of UUIDs.

This makes UUID v7 particularly useful for applications that need globally generated identifiers while also benefiting from identifiers with chronological ordering.

UUID v7 can be attractive for database keys because its ordering characteristics are generally more favorable for index insertion than completely random UUID v4 values.

UUID v7 does not replace UUID v4 in every situation.

UUID v4 remains a good choice when the primary requirement is a randomly generated identifier and chronological ordering is not important. UUID v7 is often a better choice when both globally generated identifiers and useful time ordering are desirable.

The timestamp in UUID v7 should also be considered when identifiers are exposed publicly. UUID v7 is not a secret, and its timestamp component can reveal approximate information about when an identifier was generated.

UUID Versions

UUID versions are different identifier-generation methods, not a progression where every newer version is automatically better.

Different versions are designed for different requirements.

For many new applications, UUID v4 and UUID v7 are the most relevant choices.

UUID v4 is straightforward when the application primarily needs a randomly generated identifier.

UUID v7 is useful when the application also benefits from identifiers that have a chronological ordering.

The older versions remain relevant for compatibility and specialized requirements, but there is no requirement to use the newest UUID version simply because it has a higher version number.

Choosing Between UUID v4 and UUID v7

For a new application, the choice between UUID v4 and UUID v7 usually comes down to whether ordering is useful.

Choose UUID v4 when:

• You primarily need randomly generated identifiers.
• The identifier does not need to contain a timestamp.
• Ordering provides no particular benefit.
• You want a simple and widely supported UUID format.

Choose UUID v7 when:

• You want identifiers that can be roughly ordered by creation time.
• UUIDs will be used extensively as database keys or indexed values.
• Multiple systems or services need to generate identifiers independently.
• Having a timestamp embedded in the identifier is acceptable.

Neither version is universally better. The appropriate choice depends on the application's data model, database, workload, and requirements.

Where UUIDs Are Commonly Used

UUIDs are useful anywhere an application needs an identifier that can be generated independently.

Common examples include:

• Database primary keys
• API resource identifiers
• Distributed systems
• Microservices
• Files and documents
• Transactions
• Background jobs
• Event identifiers
• Test data
• Import and synchronization processes
• Public resource identifiers

One useful characteristic is that a UUID does not reveal its position in a sequence. An integer ID such as 10001, 10002, and 10003 makes the ordering and approximate number of records obvious. A UUID does not provide that kind of sequential information.

However, UUIDs should not be selected merely because they look more secure or sophisticated. They are most valuable when independent identifier generation, distributed systems, or a large identifier namespace are useful to the application's design.

The Bottom Line

UUIDs are a practical way to generate identifiers that can be created independently across applications, servers, databases, and services with an extremely low probability of accidental collision.

UUID v4 is a strong general-purpose choice when randomly generated identifiers are appropriate. UUID v7 is a strong choice when chronological ordering is also useful.

GUID and UUID generally describe the same 128-bit identifier concept, with GUID being the terminology commonly associated with Microsoft technologies.

The important decision is not simply whether to use a UUID. It is choosing the UUID version and storage strategy that fit the application's requirements.

UUIDs are not guaranteed to be unique, they are not inherently security credentials, and they are not automatically the best database key in every situation. Used with those limitations understood, they are a well-established and highly practical identifier format for modern software systems.

More Information About UUID Versions

For a more detailed comparison of UUID versions, visit our Complete Guide to UUID Versions.

More Information About Standards

Globally Unique Identifier - Wikipedia, the free encyclopedia
GUID Structure - Microsoft.com
RFC 9562 (2024)
RFC 4122 (2005)