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

Version 1 concatenates the 48-bit MAC address of the "node" (that is, the computer generating the UUID), 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 (UTC), the date on which the Gregorian calendar was first adopted. RFC 4122 states that the time value rolls over in A.D. 3409,^[1]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.^[14]

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, 2⁷⁴ (1.8×10²², 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.^[1]

The layout of a version 1 UUID is:

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.

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

RFCs 4122 and 9562^[9] 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, the specification of version 2 UUIDs is provided by the DCE 1.1 Authentication and Security Services specification.^[6]

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.^[6] 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 once every 429.49 seconds, a little more than 7 minutes, quite different from the 100 nanosecond ticks in version 1.^[15]

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.^[9] This is useful when systems need deterministically to generate the same UUID based on a set of other names or identifiers, without coordination.

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.

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 (e.g. 0011₂ for version 3), and the 2- or 3-bit UUID "variant" (e.g. 10₂ indicating an RFC 9562^[9] UUIDs, or 110₂ 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, given the version, 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 (SHA-1) over version 3 (MD5). 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 any version as security capabilities.^[1]: 16

Version 4 (random)

A version 4 UUID is randomly generated. As in 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 (that is, most UUIDs) a random version 4 UUID will have 6 predetermined variant and version bits, leaving 122 bits for the randomly generated part, for a total of 2¹²², or 5.3×10³⁶ (5.3 undecillion) possible version 4 variant-1 UUIDs. There are half as many possible version 4, variant 2 UUIDs (legacy GUIDs) because there is one less random bit available, 3 bits being consumed for the variant.

Version 7 (timestamp and random)

Version 7 UUIDs are intended as monotonically ascending, creation-time-ordered, lexically sortable keys in large databases and distributed systems, contributing to locality and performance. With version 7 as database keys, "new" records are inserted at the logical end of the key sequence, and records which are close in time are near each other in the key sequence. This contrasts with the random version 4, which when used as database keys, are evenly and randomly dispersed across the key sequence, even when the underlying records are close in time, negatively affecting performance in many types of databases.

They are constructed as follows:

In addition to the timestamp, provision is made for a total of 74 bits for the 3 optional constructs (timestamp extra precision, seeded counter, random data) but apart from the ordering of the constructs and a requirement that at most 12 bits be used for extra timestamp precision, the number of bits allocated to each construct (including possibly 0) and the details of the constructs are left to the implementer. The 48-bit timestamps may be altered, fuzzed, or smeared for the sake of monotonicity and privacy, and it is explicitly stated that there is no requirement about how close a timestamp needs to be to the actual (Unix) time. But the intent is clear that the timestamps should be monontonic and approximate Unix time, and the RFC states that custom UUID version 8 should be used for timestamp-based designs that are not Unix time. Unlike some other UUID versions, version 7 UUIDs do not incorporate MAC addresses, and can steer clear of the privacy issues associated with them.

Version 8 (custom)

In a custom UUID, the version is 8, and the variant bits must be 10, totaling 6 bits. The remaining 122 bits are not specified.

According to the RFC, version 8 UUIDs are intended for experimental and vendor-specific use cases. The RFC suggests, for example, that this version might be used for a name/hash-based identifier generated with a newer hashing function than those specified for UUID versions 3 (MD5) and 5 (SHA-1). The RFC also suggests that version 8 can be used for timestamp-based UUID designs that do not fit within versions 6 or 7, such as a different epoch.

But version 8 is not restricted to such scenarios. In essence, version 8 UUIDs are 122 opaque bits, combined with 6 version and variant bits, which allows them to be separated from other UUID forms.

Unlike other versions, the RFC does not mandate a specific bit layout or generation algorithm, and they are not to be assumed to be unique. Unlike version 4 UUIDs, which should be 122 bits from a high-entropy source of randomness and where uniqueness and collision-resistance are subject to mathematical analysis, the uniqueness, unguessability, collision-resistance, privacy, etc of version 8 UUIDs, in general, can be relied upon based only on trust in the source (if known), out-of-band coordination, or external documentation beyond the standard. In addition, as with other UUID versions, there is no concept of version subtypes. What this means for version 8 is that in a situation where version 8 UUIDs from multiple sources and generation methods have been pooled into a single stream or database and some prove problematic, there is no way to separate the UUIDs by source, other than, perhaps, by resolving them.

Use of MAC addresses

In contrast to the other UUID versions, versions 1, 2, and 6 are based on MAC addresses from network cards, relying for their uniqueness in part on an identifier issued by a central registration authority, namely the Organizationally Unique Identifier (OUI) part of the MAC address, which is issued by the IEEE mainly to manufacturers of networking equipment.^[16] The uniqueness of the UUIDs based on network-card MAC addresses also depends on network-card manufacturers properly assigning unique MAC addresses to their cards, which like other manufacturing processes is subject to error. MAC addresses also may come from sources other than network cards. For example, virtual machines receive a MAC address from a range that is configurable in the hypervisor,^[17] and some operating systems permit the end user to customise the MAC address, notably OpenWrt.^[18] When a device has an EUI-64 64-bit "MAC address", using the least significant 48 bits of it, as recommended by the RFC, may result in the node ID part of the UUID being duplicated. Thus, node IDs based on MAC addresses may not be globally unique.

Usage of the node's network card MAC address for the node ID does often mean that version 1, 2, and 6 UUIDs can be tracked back to the computer that created them. Such UUIDs can be used to infer what kind of hardware is being used to generate the UUIDs. Documents can sometimes be traced to the computers where they were created or edited through UUIDs embedded into them by word processing software. This privacy hole was used when locating the creator of the Melissa virus.^[19]

RFC 9562^[9] does allow the MAC address in a version 1, 2 or 6 UUID to be replaced by a random 48-bit node ID, either because the node does not have a MAC address, or because it is not desirable to include it. In that case, the RFC requires that the least significant bit of the first octet of the node ID should be set to 1.^[1] This corresponds to the multicast bit in MAC addresses, and setting it serves to differentiate UUIDs where the node ID is randomly generated from UUIDs based on MAC addresses from network cards, which typically have unicast MAC addresses.^[1]

Use of timestamps

Versions 1, 2, 6, and 7 are based on, and expose, the time when the UUID was generated, which often corresponds to the creation of a record, or an historical event. If associated with people or their activity, it may be possible to infer a person's age or the precise time of their activities from UUIDs. It may be possible to determine from time-based monotonically-ascending UUIDs when a system went live, or what objects in a system are new or recently updated. If the identified objects represent product orders or user sign-ups, for example, it may be possible to determine user growth or sales volume over time from the UUIDs. Thus, time-based UUIDs, if publicly visible, may leak personal or business information, raise privacy concerns, and facilitate unwanted data mining.

Concerning the time-ordering and sortability of UUIDs, version 1 and 2 start "in the middle" with the 32 low bits of the timestamp. These two versions, along with 3-5 and 8, do not sort lexically into time order. The role of the timestamp in these UUID versions was not to make UUIDs readily orderable in time but rather to achieve universal uniqueness by fixing the generation in space and time.

Versions 6 and 7 prioritize the timestamp's role in database indexing, allowing for lexical sorting of records into chronological order. However, RFC 9562 provides significant implementation flexibility for Version 7, defining a general framework rather than a rigid bit-layout for optional sub-millisecond timestamp precision, counters, and randomness.

The specification allows the 48-bit Unix timestamp to be adjusted or "fuzzed" to maintain monotonicity (ensuring IDs created in rapid succession always increase) or to enhance privacy. Because the RFC does not define a strict maximum deviation from actual Unix time, different implementations may vary in how they balance chronological accuracy against these other requirements.^[20]

Consequently, the lexical sortability of Versions 6 and 7 UUIDs is most consistent when generated by the same library or system. Mixing UUIDs from different sources, or interleaving different versions and variants in a single database, can degrade the time-ordering and index locality that these versions were designed to provide.

RFC 9562 does not mandate a minimum number of random bits for Version 7; it allows the sub-millisecond precision and monotonicity counter fields to occupy the remainder of the 128-bit structure. Consequently, collision resistance and guessability depend entirely on the specific implementation's allocation of these bits.^[21]

Byte Ordering

Variant 1 UUIDs are sequentially encoded in big-endian. For example, 00112233-4455-6677-8899-aabbccddeeff is encoded as the bytes 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff.^[23][24]

In contrast, variant 2 UUIDs ("GUIDs"): historically used in Microsoft COM/OLE libraries, have a mixed-endian format, with the first three fields (corresponding to version 1 timestamp subfields) being little-endian, while the final two fields are emitted as big-endian arrays of bytes. The example UUID above, if it were a variant 2 UUID, would be encoded on the wire as 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff.^[25][26] All versions under variant 2 are emitted with this byte ordering, including versions not containing numeric fields, such as 3,4, and 5.