UUID Decoder – Version, Variant & Timestamp Inspector

Read defined fields, preserve uncertainty

Decode UUID structure and timestamps

Paste one UUID or a batch. The decoder validates the complete 128-bit representation before interpreting the RFC variant, version, special values, supported timestamps, clock sequence, and node fields.

Loading the UUID decoder…

Enable JavaScript to inspect UUID fields and convert supported timestamps to UTC.

Meaning depends on the version

What an RFC 9562 UUID decoder can read

Every UUID is 16 octets, commonly written as 32 hexadecimal digits in an 8-4-4-4-12 pattern. The variant is identified from the highest bits of octet 8. For the RFC 10 variant, the high four bits of octet 6 carry a version from 1 through 8. Nil and Max are special all-zero and all-one values rather than ordinary generated versions.

Version is the key to interpretation. UUID v1 and v6 define time, clock sequence, and node fields. UUID v7 defines a leading Unix-millisecond timestamp. UUID v4 assigns its payload to randomness. UUID v3 and v5 hold name-based hash output, not the original name. UUID v8 leaves payload semantics to another specification or application.

A decoder reports what the bits encode under the standard. It does not decrypt the value, contact a database, search for an issuing system, verify randomness, or authenticate the data. A well-formed UUID can be copied, fabricated, stale, unauthorized, or unrelated to any real record.

Always inspectable: Canonical bytes, text structure, variant, special status, and RFC version when applicable.
v1 and v6: Timestamp, clock sequence, and 48-bit node field.
v7: Leading 48-bit Unix millisecond timestamp.
Not reversible: Original namespace and name behind UUID v3 or v5 hash output.
Application-defined: Meaning of the custom payload in UUID v8.

Two epochs, three decodable versions

Decode UUID v1, v6, and v7 timestamps

VersionEncoded timeHow it is read

UUID v160-bit count of 100-nanosecond intervals since the Gregorian epoch.Reassemble time_high, time_mid, and time_low, then subtract the offset to the Unix epoch.

UUID v6The same Gregorian 100-nanosecond timestamp basis as v1.Read the reordered high-to-low timestamp fields, designed so the leading bytes sort by time.

UUID v748-bit unsigned Unix epoch milliseconds.Interpret the first six octets as one big-endian integer and format that instant in UTC.

UUID v1 and v6 count from 1582-10-15 00:00:00 UTC in 100-nanosecond intervals. UUID v7 counts milliseconds from 1970-01-01 00:00:00 UTC, excluding leap seconds. The decoder can preserve the exact v1 or v6 interval count while its ordinary ISO display is limited to JavaScript date range and millisecond precision.

Time is only part of the layout

UUID v1 and v6 clock sequence and node fields

For the RFC variant, UUID v1 and v6 allocate 14 bits to clock_seq. The field helps a generator avoid duplicates when the clock moves backward or the node identifier changes. A decoder can report its integer value, but the value is generator state—not a count of UUIDs and not a globally coordinated sequence.

The final 48 bits form the node field. Historical UUID v1 implementations often used an IEEE 802 MAC address, but RFC-compliant generation can use a random or pseudorandom node identifier instead. The multicast bit can distinguish a non-MAC construction in applicable methods, yet a decoded node should never be treated as authenticated hardware identity.

Version 6 reorders the v1 timestamp so its most significant time bits come first while retaining clock sequence and node concepts. That layout improves sorting, but it does not make the decoded timestamp or node trustworthy. Anyone can construct a UUID with arbitrary values in these fields.

Node is data, not attribution

A 48-bit node value may resemble a MAC address. Do not use it to identify a person, locate a device, prove network ownership, or make an access-control decision.

Read the RFC node-ID guidance →

Hash output is not stored input

Why UUID v3 and v5 inputs cannot be recovered

UUID v3 combines a namespace UUID with a name and hashes the bytes with MD5. UUID v5 follows the same overall idea with SHA-1. Each process retains the required 128-bit portion of hash output and then sets the version and variant bits. The final UUID does not carry a separate copy of the namespace, name, or full digest.

Hashing is a one-way transformation, and truncation discards additional information. A decoder therefore cannot extract the original domain name, URL, account ID, path, namespace UUID, or other source text. It can only report that the version field is 3 or 5 and show the resulting bytes.

If you already know a candidate namespace and name, an application can recompute the correct version and compare the resulting UUID. That is verification of a candidate, not recovery. Different inputs can theoretically map to the same truncated output, so the UUID alone is not proof of a unique original string.

UUID v3 algorithm: MD5 over namespace UUID bytes followed by name bytes.
UUID v5 algorithm: SHA-1 over namespace UUID bytes followed by name bytes.
Decoder can report: Version, variant, normalized UUID, and raw result bytes.
Decoder cannot recover: The namespace, original name, encoding choice, or full digest.

Avoid false precision

UUID v2, v4, and v8 decoding limits

DCE Security UUID

RFC 9562 records version 2 but leaves its detailed definition outside the standard’s scope. A generic RFC decoder can identify the version nibble without pretending to supply universal DCE semantics.

Random payload

Version 4 has 122 random or pseudorandom payload bits. There is no standard creation time, counter, node, namespace, or original input hidden inside those bits.

Custom payload

Version 8 reserves payload space for experimental or application-specific use. Decode the generic version and variant, then consult the producer’s specification for every custom field.

Unknown provenance

Even a familiar layout does not prove the generator, clock quality, entropy source, database record, issuer, or authorization context. Structure and trust are separate questions.

Presentation and bytes are different layers

Strict and normalized UUID decoding

Strict input accepts only the ordinary 36-character hex-and-dash form: 32 hexadecimal digits separated after positions 8, 12, 16, and 20. Uppercase and lowercase hexadecimal letters represent the same values, but whitespace, braces, a URN prefix, compact input, and extra suffix text are rejected.

Normalized input deliberately accepts four presentations: standard hyphenated text, exactly 32 compact hex digits, one matching pair of braces around standard text, or a case-insensitive urn:uuid: prefix followed by standard text. The decoder then reports lowercase canonical form so byte comparisons are unambiguous.

Normalization is useful for human input, but protocols and signatures may require exact source text. Do not silently rewrite a signed field, routing key, cache key, or wire value unless its governing specification defines that normalization.

Standard: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f
Compact: 017f22e279b07cc398c4dc0c0c07398f
Braced: {017F22E2-79B0-7CC3-98C4-DC0C0C07398F}
URN: urn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f

Bits can be valid and claims can still be false

What decoded UUID fields cannot prove

Not creation evidence

A v1, v6, or v7 timestamp is a field value. It does not prove when a record was committed, an event occurred, or a trusted clock observed it.

Not device identity

A node field can be random, reused, copied, or fabricated. Even a MAC-shaped value is not authenticated attribution.

Not database existence

UUID bytes do not contain a live record lookup. Query the authoritative store with proper tenant and access checks.

Not authorization

Knowing an identifier never grants permission by itself. Authenticate the caller and enforce policy for the referenced resource.

Questions answered

UUID decoder FAQ

What information can a UUID decoder read?

It can parse the 128-bit value, normalize supported text forms, classify the variant, report the RFC version, recognize Nil and Max, and decode fields whose meanings RFC 9562 defines for that version. It cannot prove who created the UUID or whether a referenced record exists.

Which UUID versions contain a decodable timestamp?

UUID v1 and v6 contain a 60-bit count of 100-nanosecond intervals since 1582-10-15 00:00:00 UTC. UUID v7 contains a 48-bit unsigned Unix millisecond value. The decoder converts those fields to UTC after confirming the RFC variant and version.

Does the UUID v1 or v6 node field always reveal a MAC address?

No. The 48-bit node field can be derived from an IEEE address or generated as a random or pseudorandom node identifier. Treat it as raw UUID data, not reliable proof of a device, network interface, location, or owner.

Can a UUID decoder recover the original UUID v3 or v5 name?

No. UUID v3 and v5 are created from a namespace UUID and a name using MD5 or SHA-1, then version and variant bits are set. The resulting truncated hash does not contain a reversible copy of those inputs, so a decoder cannot recover them.

Can a generic decoder explain every UUID v8 field?

No. RFC 9562 reserves UUID v8 for custom or experimental layouts. A generic decoder can identify version 8, the variant, and the raw 128-bit value, but only the producing specification or application can define the custom payload meaning.

What can be decoded from a UUID v4?

A decoder can confirm the text structure, RFC variant, version 4 field, canonical bytes, and special-value status. UUID v4 defines 122 random or pseudorandom payload bits, so it has no standard timestamp, clock sequence, node, namespace, or name to extract.

Is a decoded UUID timestamp trustworthy?

Not by itself. The timestamp accurately reflects the parsed bits, but any caller can construct UUID bits and a generator clock can be wrong. Do not use an untrusted UUID timestamp alone for authorization, expiration, billing, audit, or legal event time.

Can the decoder read compact UUIDs, braces, and UUID URNs?

Yes in normalized input mode. It accepts exactly 32 hexadecimal digits, a matching brace pair around standard text, or a case-insensitive urn:uuid: prefix, then reports the lowercase 8-4-4-4-12 canonical form. Strict mode requires that canonical text shape directly.

Are pasted UUIDs uploaded for decoding?

No. Parsing, field extraction, UTC conversion, normalization, and result rendering happen in the current browser tab. Clipboard history, extensions, screen sharing, and other device software remain separate privacy boundaries.