A universally unique identifier (UUID) is a 128-bit number used to identify information in computer systems. The term globally unique identifier (GUID) 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 to achieve uniqueness 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 Apollo Computer used UUIDs in the Network Computing System (NCS), launched in 1987, with a design inspired by the 64-bit unique identifiers of Domain/OS, an earlier Apollo operating system. Microsoft Windows platforms adopted the NCS (and later, the DCE) design as "Globally Unique Identifiers" (GUIDs) in the early nineties.
Somewhat later, the Open Software Foundation (OSF) used UUIDs in its Distributed Computing Environment (DCE), with a design partly based on the NCS UUIDs. This was documented in the DCE 1.1 RPC specification in 1996, and in the DCE 1.1 Authentication and Security Services specification, published in 1997. ISO/IEC documented the DCE design in 1996, in ISO/IEC 11578:1996 "Information technology – Open Systems Interconnection – Remote Procedure Call".
In July 2005, the Internet Engineering Task Force (IETF) published the Standards-Track RFC 4122., which also registered a URN namespace for UUIDs. The ITU had meanwhile 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 was technically equivalent to RFC 4122.
The current IETF specification is RFC 9562, a Proposed Standard published in May 2024. This defined three new UUID versions (6–8) of the DCE variant. The UUIDs currently in use are the DCE/IETF design, with provision for backwards compatibility with "legacy" Apollo NCS UUIDs and Microsoft GUIDs.
The authors of RFC 4122 were Paul Leach, Michael Mealling, and Rich Salz, and the authors of the initial 1997 Internet Draft were Leach and Salz. Leach had been the Architect of Domain/OS, had continued at Apollo as a designer of NCS, and then, as a Microsoft Distinguished Architect, contributed to the design of OLE/COM/DCOM, carrying the concept of UUIDs to that project.Leach was also one of the authors of RFC 9562. Salz was a member of the DCE team at the Open Software Foundation. Apollo had merged in 1989 with Hewlett-Packard, a founding member of the OSF. Former NCS team-members, having become HP employees, brought UUIDs to OSF DCE. Mealling was a prominent IETF member, holding a seat on the Internet Engineering Steering Group, and was heavily involved in IETF work on URNs. RFC 4122 brought all these strands together.
Format A UUID is a 128-bit number. The meaning of the bits is determined by the variant, of which three are defined. Of these, the most common is variant 1, with the other variants being for backwards compatibility with previous formats or for future definition. Variants 1 and 2 have "versions", which further define the interpretation of the UUID.
Variants The variant field is in a variable number of the most-significant bits of the ninth byte. In textual representations of the UUID, this is part of the hex digit after the third hyphen. It indicates the format of the UUID. The following variants are defined:
Variant 0 (indicated by the one-bit pattern 0xxx2, 016 through 716) is for backwards compatibility with the now-obsolete Apollo Network Computing System 1.5 UUID format. The variant 0 numbering space also includes the Nil UUID.
Variant 1 (10xx2, appearing as 816, 916, a16 or b16) UUIDs are referred to as RFC 4122/DCE 1.1 UUIDs, or "Leach–Salz" UUIDs, after the authors of the original Internet Draft. These are the UUIDs in current use.
Variant 2 (110x2, c16 or d16) is for backwards compatibility with the "GUIDs" used in Microsoft COM/DCOM. This format was used in early GUIDs on the Microsoft Windows platform.
Variant 3 (111x2, e16 or f16) includes the Max UUID, but is otherwise undefined and reserved for future use.
Versions The OSF DCE and Microsoft COM/DCOM variants (1 & 2, respectively) have versions, indicated by the value of the high four bits of the seventh byte of the UUID. In textual representations of the UUID, this is the hex digit after the second hyphen. Variant 0 Apollo NCS UUIDs do not have versions, being sub-typed via "address families" rather than versions. RFC 9562, which defined versions 6, 7, and 8 stated that variants other than the OSF DCE variant 1 were "out of scope" of the RFC, leaving it to Microsoft to define new versions for variant 2. However, versions 1 and 4, as standardized in RFC 4122, are the same in the Microsoft variant, except for byte-ordering.
+Comparison of UUID versions Version Type Time source Entropy/ID source Best use case 1 Time-based Gregorian (100ns) & clock seq MAC address Legacy systems; distributed uniqueness 2 DCE Security Gregorian (low-res) & clock seq Local ID (UID/GID) & node DCE-based security environments [Legacy] 3 Name-based (MD5) None (deterministic) Namespace & name Deterministic IDs; legacy name-hashing 4 Random None Cryptographic random General purpose; maximum privacy 5 Name-based (SHA-1) None (deterministic) Namespace & name Deterministic IDs; preferred over version 3 6 Time-ordered Gregorian (100ns) & clock seq MAC address or random Database keys; reordered version 1 7 Time-ordered Unix epoch (ms) Cryptographic random Modern database keys; high locality 8 Custom Variable Implementation-defined Experimental or application-specific layouts
Versions 1 and 6 (date–time and node ID) Version 1 concatenates a 48-bit node ID with a 60-bit timestamp.
The node ID is usually the MAC address of a network interface controller (NIC) on the system generating the UUID. On systems with 64-bit EUI-64 "MAC addresses", the least significant 48 bits are used.
The timestamp is the number of 100-nanosecond intervals since midnight 15 October 1582 Coordinated Universal Time (UTC), the date on which the Gregorian calendar was first adopted. RFC 4122 states that the time value rolls over in A.D. 3409, 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 A.D. 5236.
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 can advance, the lower bits of the timestamp and the clock sequence can be incremented to simulate greater precision and ensure uniqueness.
With each version-1 UUID corresponding to a single point in space (the node) and time (intervals and clock sequence), 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, 274 (1.8, or 18 sextillion) version-1 UUIDs can be generated per node ID, at a maximal average rate of 163 billion per second per node ID.
Where a system does not have a MAC address, or where the use of a MAC address is undesired, a 47-bit cryptographically secure random number may also be used. In this case, the least significant bit of the node ID, corresponding to the unicast/multicast bit of a MAC address, is set to one, preventing conflict with UUIDs derived from a MAC address.
The layout of a version-1 UUID is:
+ UUID version 1 record layout Field Width (bits) Description time_low 32 The least significant 32 bits of the 60-bit timestamp time_mid 16 The middle 16 bits of the 60-bit timestamp version 4 The 4-bit version number (0001) time_high 12 The most significant 12 bits of the 60-bit timestamp variant 2 The 2-bit variant (10) clock_seq 14 The 14-bit clock sequence node 48 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. By reinstating the original NCS hi-lo byte order of the timestamp to enable sortability, version 6 is even more similar to "legacy" variant 0 NCS UUIDs than version 1.
+ UUID version-6 record layout Field Width (bits) Description time_high 32 The most significant 32 bits of the 60-bit timestamp time_mid 16 The middle 16 bits of the 60-bit timestamp version 4 The 4-bit version number (0110) time_low 12 The least significant 12 bits of the 60-bit timestamp variant 2 The 2-bit variant (10) clock_seq 14 The 14-bit clock sequence node 48 The 48-bit node ID
Version 2 (date–time and MAC address, DCE security version) RFCs 4122 and 9562 reserve version 2 for "DCE security" UUIDs; but do not provide any details. RFC 9562 declares them "out of scope". Many UUID implementations and libraries omit version 2. However, version-2 UUIDs are defined in the DCE 1.1 Authentication and Security Services specification.
+ UUID version-2 record layout Field Width (bits) Description local_id 32 32-bit local identifier (typically a POSIX UID or GID) time_mid 16 The middle 16 bits of the 60-bit timestamp version 4 The four-bit version number (0010) time_hi 12 The high 12 bits of the timestamp variant 2 The two-bit variant (10) clock_seq_low 6 The low 6 bits of the clock sequence local_id_domain 8 Identifier domain (e.g., 0 for UID, 1 for GID) node 48 The 48-bit node ID (typically the MAC address)
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 60-bit Gregorian 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 (UIDs) and group ids (GIDs) respectively, and other local-domain numbers are site-defined. On non-POSIX systems, all local domain numbers are site-defined.
Thus, version-2 UUIDs are a way to combine a 32-bit local, node-scoped identifier of a specified 8-bit type ("domain") with the identifier of the node and a Gregorian-origin timestamp, transforming the node-scoped identifier into one that is universally unique. The tradeoff is that the timestamp is low-res in comparison to the timestamps in version 1, ticking only once every 429.49 seconds, a little more than 7 minutes, quite different from the 100 nanosecond ticks in 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 determine a UUID based on a set of other names or identifiers without reference to a central registry.
The namespace identifier is itself a UUID. The RFC 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. There is an IANA registry for additional namespace ids.