uuid generator

UUID (Universally Unique Identifier) is a 128-bit identifier standardized by the IETF under RFC 4122 and its successor RFC 9562. UUIDs are the most widely adopted unique identifier format in software engineering, supported natively by virtually every programming language, database system, and network protocol in common use. The format was originally developed in the 1980s as part of the Apollo Network Computing System and later adopted by the Open Software Foundation for the Distributed Computing Environment (DCE). Today, UUIDs serve as the default choice for generating globally unique identifiers without requiring a centralized allocation authority. The canonical text representation of a UUID is a 36-character string in the familiar 8-4-4-4-12 hexadecimal format, such as 550e8400-e29b-41d4-a716-446655440000. This representation has become one of the most recognized patterns in software development.

The UUID specification defines several versions, each using a different algorithm to generate the 128-bit value. Version 1 combines a timestamp with the generating machine's MAC address, providing uniqueness but leaking hardware identity. Version 3 and Version 5 are name-based, producing deterministic UUIDs by hashing a namespace and name with MD5 or SHA-1 respectively. Version 4, the most commonly used version, fills 122 of the 128 bits with cryptographic randomness, reserving 4 bits for the version number and 2 bits for the variant indicator. The newer versions introduced in RFC 9562 include Version 6 (reordered timestamp), UUID v7 (Unix timestamp plus random), and Version 8 (custom or experimental). Among all of these, Version 4 remains the default in most libraries and frameworks when no specific version is requested.

How UUID Works

A UUID is a 128-bit value divided into five groups when represented as a hexadecimal string. The 8-4-4-4-12 format uses hyphens as visual separators but carries no semantic meaning; the hyphens are purely for human readability. Internally, the 128 bits are organized into specific fields that vary by version.

For UUID Version 4, the generation algorithm is remarkably simple. A cryptographically secure random number generator produces 128 random bits. Six of those bits are then overwritten with fixed values: four bits are set to 0100 to indicate version 4, and two bits are set to 10 to indicate the RFC 4122 variant. This leaves 122 bits of randomness, which yields approximately 5.3 x 10^36 possible values. At this scale, the probability of a collision is vanishingly small. Even generating one billion UUIDs per second, it would take approximately 85 years to reach a 50% probability of a single collision.

The version field occupies bits 48 through 51 (the 13th hexadecimal character in the string representation), and the variant field occupies bits 64 and 65 (the 17th hexadecimal character). This is why UUID v4 values always have a 4 as the 13th character and one of 8, 9, a, or b as the 17th character. These fixed positions make it straightforward to identify the version and variant of any UUID by inspection.

For Version 1 UUIDs, the structure is different. The first 60 bits contain a timestamp based on 100-nanosecond intervals since October 15, 1582 (the date of the Gregorian calendar reform). The next 14 bits hold a clock sequence that guards against duplicate timestamps after system clock adjustments. The final 48 bits contain the IEEE 802 MAC address of the generating machine. While this provides strong uniqueness guarantees, the embedded MAC address raises privacy concerns, which is one reason Version 4 overtook Version 1 in popularity.

Regardless of version, all UUIDs share the same 128-bit size and the same canonical string format. This uniformity means that systems designed to store and compare UUIDs work identically across all versions, and version detection is simply a matter of reading the version nibble.

Use Cases

Database primary keys. UUIDs are the most common choice for primary keys in systems that need to generate identifiers without coordinating with a central database. In distributed architectures, multiple application servers can independently generate UUIDs for new records, and those records can be merged into a shared database with negligible collision risk. Most relational databases, including PostgreSQL, MySQL, and SQL Server, provide native UUID column types with optimized storage and indexing. The trade-off is that random UUID v4 values scatter inserts across B-tree index pages, which can reduce write performance at very high volumes compared to sequential identifiers.

API resource identifiers. Exposing sequential integer IDs in public APIs leaks information about the total number of resources and makes enumeration attacks trivial. UUIDs solve both problems: they are unguessable, and they reveal nothing about creation order or total count. REST APIs, GraphQL schemas, and webhook payloads frequently use UUIDs as the canonical identifier for resources such as users, orders, and transactions.

Distributed systems and message queues. In event-driven architectures, each message or event needs a unique identifier for deduplication, tracing, and correlation. UUIDs are the standard choice because every service in the pipeline can generate them independently, and the format is universally understood by logging frameworks, tracing systems, and message brokers like Kafka, RabbitMQ, and Amazon SQS.

Cross-system data integration. When merging data from multiple sources, such as during corporate acquisitions or multi-tenant platform consolidation, UUIDs prevent primary key conflicts. Each source system's records already have globally unique identifiers, so integration scripts can combine datasets without remapping keys. This property also simplifies ETL pipelines and data warehouse ingestion.

Comparison with Alternatives

The most direct evolution of UUID v4 is UUID v7, introduced in RFC 9562. UUID v7 replaces the leading random bits with a 48-bit millisecond Unix timestamp while retaining the same 128-bit size and 8-4-4-4-12 format. This makes UUID v7 a true drop-in replacement for v4 with the added benefit of chronological sorting. For new projects that use relational databases, UUID v7 is generally the better default because sequential inserts reduce index fragmentation and improve query locality. UUID v4 remains preferable when creation-time privacy is important or when the application has no use for time-based ordering.

ULID offers a similar value proposition to UUID v7: a 128-bit identifier with an embedded millisecond timestamp. The key difference is the encoding. ULIDs use Crockford's Base32, producing a 26-character case-insensitive string compared to UUID's 36 characters. ULIDs are not an IETF standard, however, which means they lack native database support and require custom column types or string storage. If compactness and human readability matter and your stack is JavaScript-centric, ULID can be a good alternative. If broad interoperability and native database support are priorities, UUID (especially v7) is the safer choice.

Nano ID takes a different approach entirely. It generates purely random identifiers of configurable length using a URL-safe alphabet, producing strings as short as 21 characters with collision resistance comparable to UUID v4. Nano ID does not embed a timestamp, version bits, or any structural metadata. This makes it ideal for short URL slugs, client-side tokens, and scenarios where identifier length must be minimized. However, the lack of standardization and the absence of time-sorting capability mean that Nano ID is not a general-purpose UUID replacement but rather a complement for specific use cases where compactness and randomness are the primary requirements.