UUID Decoder

Decode and inspect UUID structure, version, and embedded data

Try an example

UUID Input

Paste a UUID above to inspect it

UUID Structure

A UUID (Universally Unique Identifier) is a 128-bit value represented as 32 hexadecimal digits split into five groups by hyphens:

Format
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
xxxxxxxx (8)8 hex digits β€” 32 bits
xxxx (4)4 hex digits β€” 16 bits
Mxxx (4)4 hex digits β€” 16 bits. The first digit M encodes the UUID version (1–8).
Nxxx (4)4 hex digits β€” 16 bits. The first digit N encodes the UUID variant (RFC 4122, NCS, Microsoft, or reserved).
xxxxxxxxxxxx (12)12 hex digits β€” 48 bits

The version and variant are the only two fields guaranteed to be present in every UUID. All other fields depend on the version.

The Version Field

The version nibble is the first hex digit of the third group (position 14 in the full string). It identifies which UUID version was used to generate the identifier.

JavaScript
const hex = uuid.replace(/-/g, '')
const version = parseInt(hex[12], 16)  // single hex digit β†’ 1, 2, 3, 4, 5, 6, 7, or 8

Version 7 (UUID v7) is the newest widely-used version, introduced in RFC 9562 (2024). It encodes a Unix millisecond timestamp in the high bits for sortability.

The Variant Field

The variant is encoded in the high bits of the first byte of the fourth group. It identifies the layout and byte ordering conventions used by the UUID.

High bitsFirst hex digit rangeVariantDescription
0xxx xxxx0x00–0x7FNCS backward compatibilityLegacy Network Computing System (NCS) UUIDs. Reserved for backward compatibility.
10xx xxxx0x80–0xBFRFC 4122 / RFC 9562The standard RFC 4122 / RFC 9562 UUID variant. Used by all modern UUID versions (v1–v8).
110x xxxx0xC0–0xDFMicrosoft backward compatibilityLegacy Microsoft COM/DCOM GUIDs with a different byte ordering. Still encountered in Windows COM components.
111x xxxx0xE0–0xFFReservedReserved for future definition. Not used by any current UUID version.

In practice, virtually all UUIDs you encounter use the RFC 4122 / RFC 9562 variant (10xx xxxx bit pattern, first byte of the fourth group in range 0x80–0xBF). The NCS, Microsoft COM, and Reserved variants are legacy formats rarely seen in modern systems.

UUID Versions Reference

RFC 4122 defined versions 1–5. RFC 9562 (2024) added versions 6, 7, and 8:

VersionNameStandardDescription
v1Time-basedRFC 4122Timestamp (Gregorian epoch, 100ns precision) + MAC address. Sequential per host but leaks host identity.
v2DCE SecurityRFC 4122Based on UUID v1 with the time_low field replaced by a POSIX UID/GID. Rarely used outside legacy DCE/RPC systems.
v3Name-based MD5RFC 4122Deterministic: MD5 hash of a namespace UUID + name string. Same inputs always yield the same UUID. Prefer v5.
v4RandomRFC 4122122 bits of cryptographically secure randomness. The most common general-purpose UUID version.
v5Name-based SHA-1RFC 4122Like v3 but uses SHA-1. More collision-resistant than MD5. Preferred over v3 for new name-based UUIDs.
v6Reordered TimeRFC 9562Reorders the UUID v1 timestamp fields so the UUID is chronologically sortable. Defined in RFC 9562.
v7Unix TimeRFC 956248-bit Unix millisecond timestamp in high bits + random data. Sortable and B-tree index-friendly. Preferred for new time-ordered IDs.
v8CustomRFC 9562Free-form: all bits except version and variant are application-defined. No generation algorithm is specified.

Decoding UUID v1 Timestamps

UUID v1 embeds a 60-bit Gregorian timestamp (100-nanosecond intervals since October 15, 1582) split across three fields: time_low (bits 0–31), time_mid (bits 32–47), and time_hi (bits 48–59). This tool reassembles and converts them to a standard UTC date.

JavaScript
// UUID v1: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
//           ^^^^^^^^ ^^^^ ^^^^ ^^^^^ ^^^^^^^^^^^^
//           time-low  mid  hi  clk   node (MAC)
//                          ^
//                          version nibble (1)

const hex = '6ba7b8109dad11d180b400c04fd430c8'

const tLow = parseInt(hex.slice(0, 8),  16)  // 0x6ba7b810
const tMid = parseInt(hex.slice(8, 12), 16)  // 0x9dad
const tHi  = parseInt(hex.slice(13, 16), 16) // 0x1d1 (skip version nibble at index 12)

// Reconstruct 60-bit timestamp (100-ns intervals since Oct 15, 1582)
const t = (BigInt(tHi) << 48n) | (BigInt(tMid) << 32n) | BigInt(tLow)

// Subtract Gregorian offset (Oct 15, 1582 β†’ Jan 1, 1970 in 100-ns units)
const GREGORIAN_OFFSET = 122192928000000000n
const unixMs = (t - GREGORIAN_OFFSET) / 10000n

console.log(new Date(Number(unixMs)).toISOString())
// β†’ 1998-02-04T22:13:53.578Z
Note:The clock sequence field (14 bits) prevents duplicates when the clock moves backward. The node field (48 bits) is typically the MAC address of the generating host.

UUID v1 should be treated as sensitive: the embedded MAC address and precise timestamp can identify both the generating machine and the time of generation.

Decoding UUID v7 Timestamps

UUID v7 embeds a 48-bit Unix millisecond timestamp in the first 48 bits (first group + first 4 digits of second group). This tool reads those bits and converts them to a UTC date with millisecond precision.

JavaScript
// UUID v7: 018e4bc8-1000-7000-8000-000000000001
//           ^^^^^^^^^^^^
//           48-bit Unix ms timestamp

const hex = '018e4bc8100070008000000000000001'

// First 48 bits (12 hex chars) = Unix timestamp in milliseconds
const ms = parseInt(hex.slice(0, 12), 16)  // 0x018e4bc81000

console.log(new Date(ms).toISOString())
// β†’ 2024-03-11T…Z

// Everything after byte 6 is random (except version/variant bits)

Unlike UUID v1, the UUID v7 timestamp uses the familiar Unix epoch (January 1, 1970) and does not embed any host information. The remaining 74 bits are random.

How This Tool Detects UUID Version and Variant

The decoder reads position 14 (version nibble) and position 19 (variant nibble) of the canonical UUID string. No external state or context is needed β€” all information is self-contained in the UUID string.

JavaScript
// Detect UUID version from the 13th hex character (index 12)
function uuidVersion(uuid) {
  const clean = uuid.replace(/-/g, '')
  return parseInt(clean[12], 16)
}

uuidVersion('550e8400-e29b-41d4-a716-446655440000') // β†’ 4
uuidVersion('018e4bc8-1000-7000-8000-000000000001') // β†’ 7
uuidVersion('6ba7b810-9dad-11d1-80b4-00c04fd430c8') // β†’ 1

// Detect variant from the 17th hex character (index 16, first char of 4th group)
function uuidVariant(uuid) {
  const clean = uuid.replace(/-/g, '')
  const b = parseInt(clean[16], 16)
  if ((b & 0x8) === 0)      return 'NCS'
  if ((b & 0xC) === 0x8)    return 'RFC 4122'
  if ((b & 0xE) === 0xC)    return 'Microsoft'
  return 'Reserved'
}

Special UUIDs

Nil UUID

The nil UUID 00000000-0000-0000-0000-000000000000 is all zeros. It is defined by RFC 4122 as a sentinel value meaning 'no UUID' β€” analogous to null. It is not a valid generated UUID.

Max UUID

The max UUID ffffffff-ffff-ffff-ffff-ffffffffffff is all ones (0xFF in every byte). Defined in RFC 9562, it is the complement of the nil UUID and serves as a maximum sentinel value.

Frequently Asked Questions

How do I tell which version a UUID is?
Look at position 14 in the canonical UUID string (the first character of the third hyphen-separated group). That single hex digit is the version number: 1, 2, 3, 4, 5, 6, 7, or 8. Paste the UUID into this tool and it will decode the version for you.
Can I decode a UUID to recover the original data?
It depends on the version. UUID v1 and v7 embed a timestamp that can be fully recovered. UUID v1 also embeds the MAC address. UUID v3 and v5 are one-way hashes β€” you cannot recover the original name from the UUID. UUID v4 is purely random β€” there is nothing to recover.
What does 'variant' mean in a UUID?
The variant field identifies the byte layout and interpretation convention of the UUID. Almost all UUIDs you encounter will have the RFC 4122 variant (high bits 10), encoded as hex digits 8, 9, a, or b in position 19. Other variants (NCS, Microsoft) are legacy formats from the 1990s.
Why do some UUIDs look different from others?
The visual difference is in the version nibble (position 14) and variant nibble (position 19). For example, UUID v4 always has a 4 at position 14, while UUID v7 always has a 7. Within those constraints, the remaining digits are random or timestamp-derived depending on the version.
Is the nil UUID the same as an empty UUID?
Conceptually yes β€” the nil UUID (all zeros) is used to represent the absence of a UUID, similar to null. It is not a randomly generated UUID and should not be stored as a real identifier. Some systems use it as a default or placeholder value.
Can a UUID be invalid?
A UUID can be syntactically valid (correct format) but semantically unusual β€” for example, having a version nibble of 0 or a variant of 11x (reserved). The nil UUID and max UUID are syntactically valid but are sentinel values. This tool will display whatever version and variant nibbles are present and flag unrecognized versions.
What is the difference between a UUID and a GUID?
GUID (Globally Unique Identifier) is Microsoft's name for the same concept. GUIDs follow the same RFC 4122 128-bit format. The only practical difference is that legacy Microsoft GUIDs may use the Microsoft variant (high bits 110) rather than the RFC 4122 variant β€” this affects byte ordering in binary representation. Textual representation is identical.