UUIDv4 Generator

UUID version 4: The Developer's Guide

UUIDv4 is a randomly generated 128-bit identifier commonly used by software developers for database records, API resources, distributed systems, test data, transactions, files, and other objects that need an identifier that can be generated independently.

A UUIDv4 contains exactly 122 random bits. The remaining 6 bits identify the UUID version and variant. When generated using a suitable cryptographically secure random number generator, the probability of an accidental collision is extremely small.

Why Was UUIDv4 Created?

The core problem UUIDv4 addresses is independent identity generation.

In a classic monolithic application with a single database, an auto-incrementing integer is often sufficient. The database can assign the next available number whenever a record is created.

Distributed systems make this more complicated. An application may have multiple services, database shards, offline clients, or independent systems creating records at the same time. Requiring every system to contact a central authority for the next available ID introduces coordination and can create an unnecessary dependency.

UUIDv4 allows any process to generate an identifier independently. There is no central counter to maintain, and the probability of an accidental collision is extraordinarily small when UUIDs are generated correctly.

This makes UUIDv4 particularly useful when identifiers need to be created independently across multiple applications, services, devices, or databases.

Is UUIDv4 the Same as a GUID?

For practical purposes, yes.

"GUID" (Globally Unique Identifier) is a term historically associated with the Microsoft ecosystem, while "UUID" (Universally Unique Identifier) is the standardized terminology used by the relevant specifications.

In modern software development, GUID and UUID generally refer to the same 128-bit identifier concept. Microsoft's .NET System.Guid type represents a UUID-compatible identifier.

There can be implementation differences between platforms involving APIs, formatting, and byte ordering when UUIDs are converted to binary data. These details do not mean that GUIDs and UUIDs are fundamentally different types of identifiers.

Who Uses UUIDv4?

UUIDv4 is used across many areas of software development:

• Backend engineers - identifiers for records, resources, jobs, events, and correlation IDs in distributed systems
• Frontend developers - temporary or client-generated identifiers for objects that need an ID before being sent to a server
• Database administrators - database keys and indexed values where independently generated identifiers are useful
• QA and testers - unique test data that can be generated without coordinating with other test runs
• Security engineers - may encounter UUIDv4 in applications and APIs, although dedicated cryptographic token mechanisms are generally preferable for authentication credentials and password-reset tokens

The important point is that UUIDv4 is not tied to a particular programming language, database, or operating system. Any system capable of generating random UUIDs can participate in the same identifier space.

How Is UUIDv4 Used?

From a code perspective, generating a UUIDv4 is usually a simple library call that returns a 128-bit value, commonly represented as a 36-character hyphenated string.

A typical production workflow looks like this:

1. Generation - the application generates the identifier using a suitable cryptographically secure pseudo-random number generator (CSPRNG).
2. Transmission - the identifier is commonly passed as a string in JSON payloads over REST, GraphQL, or other APIs.
3. Storage - the identifier can be stored using a database's native UUID type or a compact binary representation. Some applications store UUIDs as text for interoperability, debugging, or simpler tooling.

UUIDv4 can be generated by the application before a database record exists. This is one of its most useful characteristics in distributed systems.

Exactly How Many Bits Are Random, and Why Not All 128?

A UUIDv4 is 128 bits long, but exactly 122 bits are random.

The remaining 6 bits are reserved by the UUID format:

• Version bits: 4 bits - set to 0100 to identify the UUID as version 4
• Variant bits: 2 bits - set according to the RFC 9562 variant used by modern UUIDs

These bits tell software how the UUID should be interpreted. The version distinguishes a v4 UUID from formats such as v1, v5, or v7, while the variant identifies the UUID layout being used.

The reserved bits are why a UUIDv4 does not provide a full 128 bits of random data.

With 122 random bits, UUIDv4 has:

2^122

possible random combinations, or approximately:

5.3 × 10^36

possible values.

Is UUIDv4 Suitable for Databases?

Yes, but whether it is a good database key depends on the database, workload, index design, and storage requirements.

UUIDv4 has an important advantage over sequential identifiers: the application can generate the value without first contacting the database. This is useful for distributed systems, APIs, offline applications, data synchronization, and systems where multiple services create records independently.

The main database tradeoff is that UUIDv4 values are randomly distributed.

In a B-tree index, sequential identifiers tend to insert near the current end of the index. Random UUIDv4 values can target many different index pages. In large, write-heavy workloads, this can increase page splits, reduce locality, and increase cache and I/O activity.

That does not make UUIDv4 inherently unsuitable for databases. Many applications use UUIDv4 successfully, and the practical impact depends heavily on table size, write volume, indexing strategy, database engine, hardware, and workload.

Database-specific considerations

When storage and index size matter, a native UUID type or compact 16-byte representation is generally preferable to a 36-character string.

However, storing UUIDs as text can be a reasonable choice when interoperability, debugging, existing schemas, or application tooling make it more convenient. It is a tradeoff rather than an absolute rule.

When Is UUIDv4 Appropriate?

UUIDv4 is a good fit when independently generated random identifiers are useful.

Good fits

• Public-facing identifiers - UUIDv4 does not expose a sequential record number, making simple sequential enumeration impractical. Authorization must still be enforced independently.
• Distributed generation - multiple applications, services, or devices can generate IDs without coordinating with one another.
• Offline applications - a device can create identifiers before reconnecting to a central service.
• Temporary objects - applications can assign unique identifiers to objects before they are persisted.
• Integration and synchronization - independently generated identifiers can simplify data exchange between systems.
• Non-sequential resource identifiers - UUIDs avoid exposing an obvious sequential database ID in an API or URL.

Consider alternatives when

• Database writes are extremely high-volume - random UUIDv4 primary keys may have less favorable index locality than sequential or time-ordered identifiers.
• Chronological ordering is important - UUIDv4 contains no creation-time information.
• Storage is highly constrained - a 4-byte integer requires considerably less storage than a 16-byte UUID.
• A compact URL identifier is required - alternatives such as Nano ID can provide shorter identifiers.

These are reasons to evaluate alternatives, not universal reasons to reject UUIDv4.

Is UUIDv4 Sortable?

Not by creation time.

UUIDv4 values are randomly generated, so their natural ordering has no relationship to when they were created. Sorting UUIDv4 values therefore does not produce chronological order.

If an application needs to query or sort records by creation time, it should generally maintain a separate timestamp such as created_at.

Another option is a time-ordered identifier such as UUID v7 or ULID when having time information embedded in the identifier is useful.

Is UUIDv4 Suitable for URLs?

Yes. UUIDv4 is commonly used as a resource identifier in URLs and APIs.

For example:

https://example.com/orders/550e8400-e29b-41d4-a716-446655440000

Unlike a sequential identifier such as /orders/12345, a UUIDv4 does not reveal an obvious sequence that can be incremented to discover neighboring IDs.

A properly generated UUIDv4 is also difficult to guess because of its large random space. However, this should not be treated as a security mechanism.

If a URL identifies a protected resource, the server must authenticate the request and verify that the caller is authorized to access that resource regardless of how difficult the identifier is to guess.

UUIDv4 also has a length disadvantage. A standard textual UUID occupies 36 characters, so shorter identifier formats such as Nano ID may be preferable when URL length is important.

UUIDv4 and Security

UUIDv4 should be treated as an identifier, not as a password, session credential, or authorization mechanism.

A properly generated UUIDv4 contains 122 random bits and is extremely difficult to guess. That makes it useful for identifiers where accidental discovery or sequential enumeration is a concern.

However, uniqueness and unpredictability are different properties.

Uniqueness means that independently generated identifiers are extremely unlikely to collide.

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

Applications that require authentication credentials, password-reset tokens, session tokens, API secrets, or other security-sensitive values should use purpose-built cryptographic token mechanisms rather than relying on UUIDv4 simply because it contains random data.

Comparison With Other Identifiers

The UUID family includes several versions designed for different requirements.

• UUID v1 - timestamp-based and historically includes node-related information.
• UUID v3 - deterministic, name-based UUID using MD5.
• UUIDv4 - randomly generated UUID containing 122 random bits.
• UUID v5 - deterministic, name-based UUID using SHA-1.
• UUID v6 - a reordered, time-ordered UUID based on the UUID v1 field structure.
• UUID v7 - combines a Unix timestamp with randomly generated data and is useful when chronological ordering is desirable.
• ULID - a separate 128-bit identifier format with a timestamp component and 80 bits of randomness.
• Nano ID - a compact identifier with a configurable length and alphabet. It is not a UUID and does not have a fixed 128-bit format.

Comparison Table

• UUID v1 contains a timestamp, so its fields can be ordered by creation time when represented according to its defined layout. It should not be interpreted as a guarantee of strict monotonic ordering between every generated identifier.

UUIDv4 vs UUID v7

UUIDv4 and UUID v7 are both useful for modern applications, but they solve slightly different problems.

UUIDv4 is primarily about independent random generation. It is simple, widely supported, and does not expose creation-time information.

UUID v7 adds a Unix timestamp to the identifier, making the values generally sortable by creation time while retaining randomly generated data for the remaining identifier space.

UUID v7 can therefore be attractive for database-heavy applications where chronological ordering and index locality are important.

That does not make UUID v7 a universal replacement for UUIDv4. If an application simply needs a randomly generated identifier and does not need ordering, UUIDv4 remains a straightforward and well-supported choice.

In Summary

UUIDv4 remains a practical choice for applications that need independently generated random identifiers.

Its 122 random bits provide an enormous identifier space, making accidental collisions extremely unlikely when UUIDs are generated correctly. UUIDv4 is widely supported across programming languages, databases, operating systems, and development tools.

The main tradeoff is its lack of ordering. Random UUIDv4 values can have less favorable index locality than sequential or time-ordered identifiers in some large, write-heavy database workloads.

UUID v7 is worth evaluating when chronological ordering and database index behavior are important. Other identifier formats may also be appropriate when shorter URLs, smaller storage requirements, or different generation properties matter.

The important point is not that one identifier format is universally better than another. Choose the identifier based on the application's requirements, database workload, storage constraints, and security model.

For authentication credentials, password-reset tokens, session tokens, and other security-sensitive values, use dedicated cryptographic token mechanisms rather than treating UUIDv4 itself as a security primitive.

What is the UUIDv4 Text Layout?

What is the UUIDv4 Binary Bit Layout?