Universally unique identifier

A universally unique identifier is a 128-bit number used to identify information in computer systems. The term globally unique identifier is also used, typically in software created by Microsoft.
When generated according to the standards, UUIDs are, for practical purposes, unique. Their uniqueness does not depend on a central registration authority or coordination between the parties generating them, unlike most other numbering schemes. While the probability that a UUID will be duplicated is not zero, it is close enough to zero to be negligible. Thus, anyone can create large numbers of UUIDs and use them as identifiers with near certainty that they do not duplicate UUIDs that have been, or will be, created by others, with the only coordination required being conformance with the UUID standards. Information labeled with UUIDs by independent parties can therefore coexist in the same databases or channels, with a negligible probability of duplication.
Adoption of UUIDs is widespread, with many computing platforms providing support for generating them and for parsing their textual representation.

History

In the 1980s, Apollo Computer originally used UUIDs in the Network Computing System. Later, the Open Software Foundation used UUIDs for their Distributed Computing Environment. The design of the DCE UUIDs was partly based on the NCS UUIDs, whose design was in turn inspired by the unique identifiers defined and used pervasively in Domain/OS, an operating system designed by Apollo Computer. Later in the early 1990s, the Microsoft Windows platforms adopted the DCE design as "Globally Unique IDentifiers".

Standards

UUIDs were standardized by various bodies, starting with the Open Software Foundation in 1996-1997, part of the Distributed Computing Environment.. The definition was also documented in 1996 as part of ISO/IEC 11578:1996 "Information technology – Open Systems Interconnection – Remote Procedure Call.
In July 2005, the Internet Engineering Task Force published the Standards-Track RFC 4122. RFC 4122 also registered a URN namespace for UUIDs. The ITU had also standardized UUIDs, based on the previous standards and early versions of RFC 4122, in ITU-T Rec. X.667 ISO/IEC 9834-8. This is technically equivalent to RFC 4122.
In May 2024, RFC 9562 was published, introducing 3 new "versions", clarifying some ambiguities, and superceding RFC 4122. This applies only to "variant 1" of the RFC 4122 UUID definition, with the other variants being out of scope.

Format

A UUID is a 128-bit number, in which 1 to 3 bits are used to indicate the UUID variant. The two most common variants further define 4 bits as the version of the UUID, with eight versions currently specified. The generation of the remaining bits is governed by the variant/version selected.

Variants

The variant field indicates the format of the UUID. The following variants are defined:

The Apollo NCS variant 0 is for backwards compatibility with the now-obsolete Apollo Network Computing System 1.5 UUID format developed around 1988. The variant field of current UUIDs overlaps the address family octet in NCS UUIDs in such a way that any NCS UUIDs still in use have a 0 in the first bit of the variant field.
The OSF DCE variant 1 UUIDs are referred to as RFC 4122/DCE 1.1 UUIDs, or "Leach–Salz" UUIDs, after the authors of the original Internet Draft.
The Microsoft COM/DCOM variant 2 is characterized in the RFC as "reserved, Microsoft Corporation backward compatibility" and was used for early GUIDs on the Microsoft Windows platform. The main difference between this variant and variant 1, aside from the extra variant bit, is byte-ordering within the UUID. Current Microsoft tools do not generate this variant. Also, RFC 9562, which added versions 6, 7, and 8, states that the variants other than variant 1 are out of its scope though this is unlikely to result in interoperability problems in practice. The versions applicable to the legacy Microsoft variant 2 are therefore somewhat unclear, but likely include only versions 1, 3, and 4.
Variant 3 is reserved.
Versions

The OSF DCE and Microsoft COM/DCOM variants have versions, indicated by the value of the high 4 bits of the 7th byte of the UUID. In textual representations of the UUID, this is the character after the second hyphen.

Versions 1 and 6 (date-time and MAC address)

Version 1 concatenates the 48-bit MAC address of the "node", with a 60-bit timestamp. On systems with 64-bit EUI-64 "MAC addresses", the least significant 48 bits are used. A 48-bit random number may also be used.
The timestamp is the number of 100-nanosecond intervals since midnight 15 October 1582 Coordinated Universal Time, the date on which the Gregorian calendar was first adopted in parts of Europe. RFC 4122 states that the time value rolls over around 3400 AD, depending on the algorithm used, which implies that the 60-bit timestamp is a signed quantity. However some software, such as the libuuid library, treats the timestamp as unsigned, putting the rollover time in 5623 AD.
A 13-bit or 14-bit "uniquifying" clock sequence extends the timestamp in order to handle cases where the processor clock does not advance fast enough, or where there are multiple processors and UUID generators per node. When UUIDs are generated faster than the system clock could advance, the lower bits of the timestamp fields can be generated by incrementing it every time a UUID is being generated, to simulate a higher-resolution timestamp.
With each version 1 UUID corresponding to a single point in space and time, the chance of two properly generated version 1 UUIDs being unintentionally the same is practically nil. Since the time and clock sequence total 74 bits, 2⁷⁴ version 1 UUIDs can be generated per node ID, at a maximal average rate of 163 billion per second per node ID.
The layout of a version 1 UUID is:

Name	Length	Length	Contents
time_low	4	8	integer giving the low 32 bits of the time
time_mid	2	4	integer giving the middle 16 bits of the time
time_hi_and_version	2	4	4-bit "version" in the most significant bits, followed by the high 12 bits of the time
clock_seq_hi_and_res clock_seq_low	2	4	1 to 3-bit "variant" in the most significant bits, followed by the 13 to 15-bit clock sequence
node	6	12	the 48-bit node id

Version 6 is the same as version 1 except for the order of the timestamp bits. In Version 6, timestamp bits are ordered from most significant to least significant. This allows systems to sort version 6 UUIDs in order of creation simply by sorting them lexically.

Version 2 (date-time and MAC address, DCE security version)

RFC 9562 reserves version 2 for "DCE security" UUIDs; but it does not provide any details. For this reason, many UUID implementations omit version 2. However, the specification of version 2 UUIDs is provided by the DCE 1.1 Authentication and Security Services specification.
Version 2 UUIDs are similar to version 1, except that the least significant 8 bits of the clock sequence are replaced by a "local domain" number, and the least significant 32 bits of the timestamp are replaced by an integer identifier meaningful within the specified local domain. On POSIX systems, local-domain numbers 0 and 1 are for user ids and group ids respectively, and other local-domain numbers are site-defined. On non-POSIX systems, all local domain numbers are site-defined.
The ability to include a 40-bit domain/identifier in the UUID comes with a tradeoff. On the one hand, 40 bits allow about 1 trillion domain/identifier values per node ID. On the other hand, with the clock value truncated to the 28 most significant bits, compared to 60 bits in version 1, the clock in a version 2 UUID will "tick" only once every 429.49 seconds, a little more than 7 minutes, as opposed to every 100 nanoseconds for version 1. And with a clock sequence of only 6 bits, compared to 14 bits in version 1, only 64 unique UUIDs per node/domain/identifier can be generated per 7-minute clock tick, compared to 16,384 clock sequence values for version 1.

Versions 3 and 5 (namespace name-based)

Version 3 and version 5 UUIDs are generated by hashing a namespace identifier and name. Version 3 uses MD5 as the hashing algorithm, and version 5 uses SHA-1. This is useful when systems need to generate the same UUID based on a set of other names or identifiers, without coordination.
The namespace identifier is itself a UUID. The specification provides constant UUIDs to represent the namespaces for URLs, fully qualified domain names, object identifiers, and X.500 distinguished names; but any desired UUID may be used as a namespace designator.
To determine the version 3 UUID corresponding to a given namespace and name, the UUID of the namespace is transformed to a string of bytes, concatenated with the input name, then hashed with MD5, yielding 128 bits. Then 6 or 7 bits are replaced by fixed values, the 4-bit version, and the 2- or 3-bit UUID "variant". Since 6 or 7 bits are thus predetermined, only 121 or 122 bits contribute to the uniqueness of the UUID.
Version 5 UUIDs are similar, but SHA-1 is used instead of MD5. Since SHA-1 generates 160-bit digests, the digest is truncated to 128 bits before the version and variant bits are replaced.
Version 3 and version 5 UUIDs have the property that the same namespace and name will map to the same UUID. However, neither the namespace nor name can be determined from the UUID, even if one of them is specified, except by brute-force search. RFC 4122 recommends version 5 over version 3. This is because it is believed that MD5 is more prone to collisions than SHA-1, though MD5 is somewhat faster. The RFC warns against use of UUIDs of either version as security credentials.