Universally unique identifier (UUID)

A universally unique identifier ( UUID ) — is a 128-bit label used for information in computer systems. The term Globally Unique Identifier ( GUID ) is also used, mainly in Microsoft systems.

When generated according to standard methods, 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. Although the probability that a UUID will be duplicated is not zero, it is generally considered close enough to zero to be negligible.

Thus, anyone can create a UUID and use it to identify something with near-complete confidence that the identifier does not duplicate one that has already been, or will be, created to identify something else. Therefore, information tagged with UUIDs by independent parties can later be combined into a single database or transmitted over the same channel with a negligible probability of duplication.

The use of UUIDs is widespread, and many computing platforms support their generation and the parsing of their textual representation.

In the 1980s, Apollo Computer originally used UUIDs in the Network Computing System (NCS). Later, the Open Software Foundation (OSF) used UUIDs for its Distributed Computing Environment (DCE). The design of the DCE UUID was partly based on the NCS UUID, whose design in turn was inspired by (64-bit) unique identifiers defined and widely used in Domain/OS, an operating system developed by Apollo Computer. ^{[ 6 ]} Later, Microsoft Windows platforms adopted the DCE design as «Globally Unique Identifiers» (GUIDs).

RFC 4122 registered the URN namespace for UUIDs and reiterated earlier specifications with the same technical content. ^{[ 2 ]} When RFC 4122 was published as a proposed IETF standard in July 2005, the ITU also standardized UUIDs based on previous standards and earlier versions of RFC 4122. On May 7, 2024, RFC 9562 was published, introducing 3 new «versions» and clarifying some ambiguities.

UUIDs were standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE).

UUIDs are documented as part of ISO/IEC 11578:1996 «Information technology – Open Systems Interconnection – Remote Procedure Call (RPC)» and, more recently, in ITU-T Rec. X.667 | ISO/IEC 9834-8:2014.

The Internet Engineering Task Force ( IETF ) published the Standards-Track document RFC 9562 [ 1 ] from the «Universally Unique IDentifiers Revision Working Group» [ 10 ] as a revised version of RFC 4122 . [ 2 ] RFC 4122 is technically equivalent to ITU-T Rec. X.667 | ISO/IEC 9834-8, but is now obsolete.

A UUID is 128 bits in size, of which 2 to 4 bits are used to indicate the format variant. The most common variant used today, OSF DCE, additionally defines 4 bits for its version.

The use of the remaining bits is governed by the chosen variant/version.

The variant field indicates the format of the UUID (and, in the case of legacy UUIDs, also the address family used for the node field). The following variants are defined:

• The Apollo NCS variant (denoted by the single-bit pattern 0xxx 2 ) is intended for backward compatibility with the now-obsolete Apollo Network Computing System 1.5 UUID format, developed around 1988. Although it differs in detail, its similarity to modern UUIDv1 is evident. The variant bits in the current UUID specification coincide with the upper bits of the address-family octet in NCS UUIDs. Although the address family could contain values in the range 0..255, only the values 0..13 were ever defined. Accordingly, the bit pattern 0xxx avoids conflicts with historical NCS UUIDs, should any still exist in databases. [ 11 ] This variant defines «families» as a subtype.
• The OSF DCE variant (10xx ₂ ) is referred to as an RFC 4122/DCE 1.1 UUID or a "Leach–Salz" UUID, after the authors of the original Internet Draft . This variant defines "versions" as a subtype.
• The Microsoft COM/DCOM variant (110x ₂ ) is characterized in the RFC as «reserved, backward compatibility with Microsoft Corporation» and was used for early GUID identifiers on the Microsoft Windows platform.
• The reserved variant space is currently not used by any specification.

The OSF DCE variant defines eight «versions» in the standard, and each version may be more suitable than the others for particular use cases. The version is indicated by the value of the most significant nibble (the upper 4 bits, or the most significant hex digit) of the 7th byte of the UUID. In hexadecimal form, this is the character after the second dash. For example, a UUID is version 4, since the digit after the second dash is 4 in it.

9c5b94b1-35ad-49bb-b118-8e8fc24abf80...-49bb-...

Version 1 combines the 48-bit MAC address of the «node» (i.e. the computer generating the UUID) with a 60-bit timestamp representing the number of 100-nanosecond intervals since midnight on October 15, 1582, Coordinated Universal Time (UTC) — the date on which the Gregorian calendar was first adopted by most of Europe, which at the time was dominated by Roman Catholic Spain. RFC 4122 states that the time value rolls over around the year 3400 AD, depending on the algorithm used, implying that the 60-bit timestamp is a signed quantity. However, some software, such as the libuuid library, treats the timestamp as unsigned, setting the rollover time to 5623 AD. The rollover time, as defined in ITU-T Rec. X.667, is 3603 AD.

A 13-bit or 14-bit «uniquifying» clock sequence extends the timestamp to handle cases where the processor clock does not advance fast enough, or where a node has several processors and UUID generators. When UUIDs are generated faster than the system clock can advance, the low-order bits of the timestamp fields can be generated by incrementing them each time a UUID is generated, to simulate a high-resolution timestamp. Because each version 1 UUID corresponds to a single point in space (node) and time (timestamp and clock sequence), the probability that two correctly generated version 1 UUIDs will be unintentionally identical is practically zero. Since the timestamp and clock sequence together amount to 74 bits, 2 ⁷⁴ (1.8 × 10²² (or 18 sextillion) version 1 UUIDs can be generated per node identifier, with an average maximum rate of 163 billion per second per node identifier.

Unlike other UUID versions, version 1 and version 2 UUIDs, based on network card MAC addresses, partially rely on an identifier issued by a central registration authority, namely the Organizationally Unique Identifier (OUI) portion of the MAC address, which is issued by the IEEE to network hardware manufacturers. The uniqueness of version 1 and version 2 UUIDs based on network card MAC addresses also depends on network card manufacturers correctly assigning unique MAC addresses to their cards, which, like other manufacturing processes, is subject to errors. Virtual machines are assigned a MAC address from a range configured in the hypervisor. In addition, some operating systems allow the end user to configure the MAC address, notably OpenWRT .

Using the node's network card MAC address for the node identifier means that a version 1 UUID can be traced back to the computer that created it. Documents can sometimes be traced back to the computers on which they were created or edited via UUIDs embedded in them by word-processing software . This privacy hole was used in the search for the creator of the Melissa virus .

RFC 9562 allows the MAC address in a version 1 (or 2) UUID to be replaced with a random 48-bit node identifier, either because the node has no MAC address, or because it is undesirable to disclose it. In this case, the RFC requires that the least significant bit of the first octet of the node identifier be set to 1. This corresponds to the multicast bit in MAC addresses, and setting it serves to distinguish UUIDs where the node identifier is randomly generated from UUIDs based on network card MAC addresses, which typically have unicast MAC addresses.

Version 6 is the same as version 1, except that all the timestamp bits are ordered from most significant to least significant. This allows systems to sort UUIDs in order of creation simply by sorting them lexically, whereas this is not possible with version 1.

RFC 9562 reserves version 2 for "DCE security" UUIDs, but does not provide any details. For this reason, many UUID implementations omit version 2. However, the version 2 UUID specification 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 intended for user identifiers ( UID ) and group identifiers ( GID ) respectively, while 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 a UUID comes with a trade-off. On the one hand, 40 bits allow for about 1 trillion domain/identifier values per node identifier. On the other hand, since the clock value is truncated to the 28 most significant bits, compared to 60 bits in version 1, the clock in a version 2 UUID will only «tick» once every 429.49 seconds, a little over 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.

Version 3 and version 5 UUIDs are generated by hashing a namespace identifier and a name. Version 3 uses MD5 as the hashing algorithm, while version 5 uses SHA-1 .

Version-3 and version-5 are generated based on a "namespace" and a unique "name". The namespace and name are concatenated and hashed. Neither version has a time or random component, so the same input always produces the same output.

• namespace — a UUID
• name — can be anything

What is the difference between version 3 and version 5?

• Version 3 UUIDs are based on the MD5 hash of the name and namespace.
• Version 5 UUIDs are based on the SHA-1 hash of the name and namespace.

The namespace identifier is itself a UUID. The specification provides UUIDs to represent namespaces for URLs , fully qualified domain names , object identifiers , and X.500 distinguished names ; but any desired UUID can be used as a namespace pointer.

To determine the version 3 UUID corresponding to a given namespace and name, the namespace UUID is converted to a string of bytes, concatenated with the input name, then hashed using MD5, producing 128 bits. Then 6 or 7 bits are replaced with fixed values: a 4-bit version (e.g. 0011 ₂ for version 3) and a 2- or 3-bit UUID «variant» (e.g. 10 _2, indicating an RFC 9562 UUID, or 110 _2, indicating a legacy Microsoft GUID). 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 always map to the same UUID. However, neither the namespace nor the name can be determined from the UUID, even if one of them is specified, except by brute-force search. RFC 4122 recommends version 5 (SHA-1) over version 3 (MD5) and cautions against using UUIDs of either version as security credentials.

Predefined namespaces:

• DNS —6ba7b810-9dad-11d1-80b4-00c04fd430c8
• URL —6ba7b811-9dad-11d1-80b4-00c04fd430c8
• OID —6ba7b812-9dad-11d1-80b4-00c04fd430c8
• X.500 DN —6ba7b814-9dad-11d1-80b4-00c04fd430c8

When using a predefined namespace identifier, we convert that identifier to an internal UUID.

When using our version 3 or 5 UUID generators, you will be prompted to enter a «namespace» (or a predefined UUID identifier) and a «name».

A version 4 UUID is generated randomly. As with other UUIDs, 4 bits are used to indicate version 4, and 2 or 3 bits to indicate the variant (10 ₂ or 110 ₂ for variants 1 and 2 respectively). Thus, for variant 1 (i.e. the majority of UUIDs), a random version 4 UUID will have 6 predetermined variant and version bits, leaving 122 bits for the randomly generated portion, giving a total of 2 ¹²² , or 5.3 × 10³⁶ (5.3 undecillion) possible variant 1 version 4 UUIDs. There are half as many possible variant 2 version 4 UUIDs (legacy GUIDs), since one fewer random bit is available, with 3 bits consumed for the variant.

According to RFC 9562 , the 4 most significant bits of the seventh octet indicate which version the UUID corresponds to. This means the first hex digit in the third group always starts with a in UUIDv4s. Visually, this looks like , where — is the UUID version field. The upper two or three bits of the digit encode the variant. For example, a random version 4, variant 2 UUID might be . 4xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxxMN8D8AC610-566D-4EF0-9C22-186B2A5ED793

Version 7 UUIDs (UUIDv7) are intended for use as keys in high-load databases and distributed systems.

A UUIDv7 starts with a 48-bit big-endian Unix Epoch timestamp with approximately millisecond granularity. The timestamp can be shifted by an arbitrary time-shift value. Immediately following the timestamp is the version nibble, which must have the value 7. The variant bits must be 10x. The remaining 74 bits are a randomly seeded counter (optional, at least 12 bits but no more than 42 bits) plus random data.

Two methods for handling counter rollover can be used together:

• The most significant, leftmost guard bit of the counter has a value of zero.
• Advance the timestamp to the actual time and reinitialize the counter when it overflows.

In a DBMS, the UUIDv7 generator can be shared across threads (bound to a table or to the DBMS instance) or can be local to a thread (with worse monotonicity, locality, and performance).

Version 8 has only two requirements:

• The variant bits must be 10x.
• The version nibble value must equal 8.

These requirements tell the system that this is a version 8 UUID. The remaining 122 bits are customized by the vendor. The difference from version 4 is that those 122 bits are random, whereas the 122 bits in a version 8 UUID are not, since they follow rules defined by the vendor.

The «nil» UUID is the UUID 00000000-0000-0000-0000-000000000000, i.e. all bits set to zero. This special-case UUID is guaranteed not to be unique.

This UUID can be used as a template for the UUID format, or when you need an easily identifiable UUID that is guaranteed not to be unique.

The «maximum» UUID, sometimes also called the «omni» UUID, is the UUID FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, i.e. one with all bits set to one.

Apollo Computer originally designed the UUID with the following wire format:

Later, the UUID was extended by combining the legacy family field with a new variant field. Since the family field had only ever used values from 0 to 13, it was decided that a UUID with the most significant bit set to 0 is a legacy UUID. This gives the following table for the family group:

The legacy Apollo NCS UUID has the format described in the previous table. The OSF DCE UUID variant is described in RFC 9562. The Microsoft COM/DCOM UUID has its own variant described in Microsoft documentation.

When stored in binary form, UUIDs are consistently encoded in big-endian order. For example, 00112233-4455-6677-8899-aabbccddeeffis encoded as the bytes 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff.

An exception to this rule are Microsoft's variant 2 («GUID») UUIDs: historically used in COM/OLE libraries, they use little-endian format, but appear mixed, with the first three components of the UUID in little-endian order and the last two in big-endian order, due to missing byte separators when formatted as a string. For example, 00112233-4455-6677-8899-aabbccddeeffis encoded as the bytes 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff.

In most cases, UUIDs are represented as hexadecimal values. The most commonly used format is the 8-4-4-4-12 format, xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxwhere each xrepresents 4 bits. Other well-known formats include the 8-4-4-4-12 format with curly braces, {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}as in Microsoft systems such as Windows, or xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, with all dashes removed. In some cases it is also possible to use a «0x» prefix or an «h» suffixxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx to indicate hexadecimal values. The dashed format was introduced with the new variant system. Before that, the legacy Apollo format used a slightly different format: 34dc23469000.0d.00.00.7c.5f.00.00.00. The first part is the time (time_high and time_low together). The reserved field is omitted. The family field comes right after the first dot, so in this case 0d(13 in decimal) stands for DDS (Data Distribution Service) . The remaining parts, each separated by a dot, are the node bytes.

Lowercase hexadecimal format is generally the preferred format. In particular, in some contexts, such as those defined in ITU-T Recommendation X.667, lowercase is required when generating text, but the uppercase version must also be accepted.

A UUID can be represented as a 128-bit integer. For example, the UUID 550e8400-e29b-41d4-a716-446655440000can also be represented as 113059749145936325402354257176981405696. Note that both signed and unsigned values are possible if the first bit of the UUID is set to 1.

A UUID can be represented as a 128-bit binary number . For example, the UUID 550e8400-e29b-41d4-a716-446655440000can also be represented as 0101010100001110100001000000000111000101001101101000001110101001010011100010110010001000110011001010101010001000000000000000.

RFC 9562 registers the "uuid" namespace. This allows URNs to be created from UUIDs, for example

urn:uuid:550e8400-e29b-41d4-a716-446655440000.

For this, the usual 8-4-4-4-12 format is used. It is also possible to create OID URNs from UUIDs, for example

urn:oid:2.25.113059749145936325402354257176981405696.

In this case, unsigned decimal format is used. The "uuid" URN is recommended over the "oid" URN.

A collision occurs when the same UUID is generated more than once and assigned to different referents. In the case of standard version 1 and version 2 UUIDs using unique network card MAC addresses, collisions are unlikely, and the probability increases only when the implementation deviates from the standards, whether unintentionally or intentionally.

Unlike version 1 and version 2 UUIDs generated using MAC addresses, with version 1 and 2 UUIDs that use randomly generated node identifiers, hash-based version 3 and version 5 UUIDs, and random version 4 UUIDs, collisions can occur even without implementation issues, although with such a low probability that it can generally be ignored. This probability can be precisely calculated based on an analysis of the birthday problem .

For example, the number of random version 4 UUIDs that need to be generated to have a 50% probability of at least one collision is 2.71 quintillion, calculated as follows:

n≈12+14+2×ln⁡(2)×2122≈2.71×1018.

This number is equivalent to generating 1 billion UUIDs per second for about 86 years. A file containing that many UUIDs, at 16 bytes per UUID, would be about 45 exabytes in size.

The smallest number of version 4 UUIDs that need to be generated for the probability of detecting a collision to equal p, is approximated by the formula

2×2122×ln⁡11−п.

Thus, the probability of finding a duplicate among 103 trillion version 4 UUIDs is one in a billion.

Collisions have occurred when manufacturers assigned a default UUID to a product, such as a motherboard, and then failed to overwrite the default UUID later in the manufacturing process.

For example, the UUID 03000200-0400-0500-0006-000700080009 is found on many different units of Gigabyte-branded motherboards.

Significant applications include the ext2 / ext3 / ext4 filesystem user-space tools ( e2fsprogs uses libuuid, provided by util-linux ), LVM , LUKS encrypted partitions , GNOME , KDE , and macOS , most of which are derived from the original implementation by Theodore Ts'o . The «partition label» and «partition UUID» are both stored in the superblock . They are both part of the filesystem, not of the partition. For example, ext2–4 contain a UUID, while NTFS or FAT32 do not. The superblock is part of the filesystem and is thus entirely contained within the partition; hence after dd if=/dev/sda1 of=/dev/sdb1, both sda1 and sdb1 have the same label and UUID.

Microsoft's Component Object Model (COM) uses several kinds of GUID :

• IID – interface identifier; (Those registered on the system are stored in the Windows registry at [HKEY_CLASSES_ROOT\Interface]^[ )
• CLSID – class identifier; (Stored in [HKEY_CLASSES_ROOT\CLSID])
• LIBID – type library identifier; (Stored in [HKEY_CLASSES_ROOT\TypeLib] )
• CATID – category identifier; (its presence on a class identifies it as belonging to certain class categories listed in [HKEY_CLASSES_ROOT\Component Categories] )

UUIDs are commonly used as a unique key in database tables . The NEWID function in Microsoft SQL Server's version 4 Transact-SQL returns standard random version 4 UUIDs, while the NEWSEQUENTIALID function returns 128-bit UUID-like identifiers that are guaranteed to increase in order until the next system reboot. Oracle Database's SYS_GUID function does not return a standard GUID, despite the name. Instead, it returns a 16-byte, 128-bit RAW value based on the host identifier and the process or thread identifier, somewhat resembling a GUID. PostgreSQL has a UUID data type [ 35 ] and can generate most UUID versions using functions from modules. MySQL provides a UUID function that generates standard version 1 UUIDs.

The random nature of standard version 3, 4, and 5 UUIDs, as well as the field order in standard versions 1 and 2, can create locality or performance problems for a database when UUIDs are used as primary keys . For example, in 2002 Jimmy Nilsson reported a significant performance improvement with Microsoft SQL Server when version 4 UUIDs used as keys were modified to include a non-random suffix based on the system time. This so-called «COMB» (combined time-GUID) approach significantly increased the probability of UUID duplication, as Nilsson acknowledged, but Nilsson only required uniqueness within the application. By reordering and encoding version 1 and 2 UUIDs so that the timestamp comes first, the loss of insert performance can be avoided.

Corresponding COMB-like UUID payload structures were eventually standardized in RFC 9562 as UUIDv6 and UUIDv7.

• Birthday attack
• Object identifier (OID)
• Uniform Resource Identifier (URI)
• Snowflake ID
• Call sign
• Mail ID
• Employee number
• Unique transaction identifier
• Bibcode
• E.164
• GUID
• Identicon
• SKU
• Unique Device Identification
• Network addressing‎
• Barcode
• Identifier
• Common noun
• Identifier
• Unique identifiers‎