UUID Generator

A Universally Unique Identifier (UUID) is a 128-bit label used to uniquely identify information in computer systems. Defined by RFC 4122 and standardized by the Open Software Foundation, UUIDs are designed so that any system can generate one independently without significant risk of creating a duplicate. This property makes them indispensable in distributed systems, databases, APIs, and anywhere that globally unique identifiers are needed without a central authority to assign them.

UUID Versions Explained

The UUID specification defines five versions, each with a different method of generation. Version 1 uses the host's MAC address combined with a timestamp, guaranteeing uniqueness as long as the MAC address is unique and the clock does not go backwards. Version 2 is a DCE Security variant rarely used in practice. Version 3 generates a UUID by hashing a namespace identifier and name with MD5. Version 4, the most commonly used, generates all significant bits randomly or pseudo-randomly. Version 5 is similar to version 3 but uses SHA-1 instead of MD5.

Version 4 UUIDs are by far the most popular in modern software development. Their generation requires no network access, no hardware identifiers, and no shared state between systems. A compliant implementation needs only a source of randomness — ideally a cryptographically secure one such as the browser's crypto.getRandomValues API or the operating system's /dev/urandom. This simplicity, combined with an astronomically low collision probability, has made UUID v4 the default choice for most applications.

The Structure of a UUID v4

A UUID v4 is written as 32 hexadecimal digits displayed in five groups separated by hyphens, following the pattern 8-4-4-4-12. For example: 550e8400-e29b-41d4-a716-446655440000. The total is 36 characters including hyphens, or 32 characters without them.

Despite being called 'random,' a UUID v4 has two fixed fields. Bits 48 through 51 (the 13th hex digit) are always set to 0100 in binary — the digit 4 — indicating that this is a version 4 UUID. Bits 64 and 65 (the 17th hex digit) are set to 10 in binary, restricting the first digit of the fourth group to 8, 9, a, or b. This is called the variant field and indicates the UUID follows the RFC 4122 layout. The remaining 122 bits are random, providing 2^122 (approximately 5.3 times 10^36) possible unique identifiers.

Collision Probability

One of the most common questions about UUIDs is whether two systems can accidentally generate the same one. The answer is that while it is theoretically possible, the probability is so astronomically small that it is not a practical concern. To have a 50% chance of at least one collision, you would need to generate approximately 2.7 times 10^18 UUIDs — that is 2.7 quintillion. For context, if every person on Earth generated a UUID every second, it would take over 10 billion years to reach that threshold.

This analysis assumes a properly implemented random number generator. Using a weak or predictable source of randomness — such as Math.random() in some JavaScript engines — can significantly increase collision risk. For production systems, always use a cryptographically secure random number generator. In browsers, crypto.getRandomValues() provides this guarantee. In Node.js, the crypto module serves the same purpose. This generator uses crypto.getRandomValues to provide proper randomness.

Common Use Cases

UUIDs appear throughout modern software infrastructure. Database primary keys are one of the most frequent applications — using UUIDs instead of auto-incrementing integers allows records to be created on any node of a distributed database without coordination. This is essential for horizontally scaled systems where multiple database replicas accept writes simultaneously.

API request identifiers use UUIDs to trace requests through microservice architectures. Each incoming request is assigned a UUID that propagates through every service call, making it possible to correlate log entries across dozens of systems. Session tokens, file identifiers, message queue deduplication keys, and temporary resource names are all common UUID applications.

In frontend development, UUIDs are frequently used as React component keys, IndexedDB record identifiers, and client-side tracking tokens. The ability to generate a globally unique identifier without a server round-trip is valuable for optimistic UI updates, offline-capable applications, and reducing latency in user interactions.

UUID v7 and the Future

The newer UUID v7 specification, proposed in RFC 9562, embeds a Unix timestamp in the most significant bits of the UUID. This means that UUID v7 values are roughly sortable by creation time — a significant advantage for database indexing, since B-tree indexes perform better when inserts are approximately sequential. UUID v7 retains the randomness property for the remaining bits, preserving collision resistance while adding temporal ordering.

Despite the advantages of UUID v7, version 4 remains the standard for most general-purpose use cases. Its simplicity, widespread library support, and complete independence from time or hardware make it the safest default choice. When choosing between versions, consider whether sort order matters for your application. If not, UUID v4 is the right choice. If you need time-sortable identifiers with the uniqueness guarantees of UUIDs, v7 may be preferable.