{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ variantBadge }} {{ formatBadge }} {{ report.preferred_uuid }}

UUID source inspection
The first non-empty token is decoded. The value may use upper- or lowercase hexadecimal characters.
Only the first non-empty line was decoded; {{ ignoredLineCount }} extra line{{ ignoredLineCount === 1 ? '' : 's' }} ignored.
Formatting changes only the text representation, not the decoded UUID.
Versions without an RFC-defined timestamp remain unchanged.
General keeps the neutral RFC review; other choices add one context-specific note.
Off is neutral and permits inspection of Nil, Max, legacy NCS, Microsoft, and future-reserved layouts.
{{ strict_variant ? 'On' : 'Off' }}
FieldBitsValueMeaningCopy
{{ row.field }}{{ row.bits }}{{ row.value }}{{ row.meaning }}

{{ fieldsExportStatus }}

SignalCheckEvidenceNext stepCopy
{{ row.signal }}{{ row.check }}{{ row.evidence }}{{ row.next_step }}

{{ reviewExportStatus }}

{{ chartExportStatus }}

{{ workflowAnnouncement }}

Database rows, API requests, and log records often need identifiers that separate systems can create without asking one central service for the next number. A UUID supplies an independently generated identifier in 128 bits, with a very low collision risk when its generation method is sound.

The familiar text form contains 32 hexadecimal digits grouped as 8-4-4-4-12. Those hyphens make the value readable but do not add information. Braces, uppercase letters, compact hexadecimal, and a urn:uuid: prefix are alternative representations of the same 128 bits.

Two marker fields determine how the remaining bits may be interpreted. The variant identifies the broad layout, while the version identifies a construction within the RFC variant. A version 4 UUID mainly carries random or pseudorandom data. Versions 1 and 6 carry Gregorian-epoch time and node fields. Version 7 starts with Unix time in milliseconds. Versions 3 and 5 are deterministic name-based values, and version 8 reserves the payload for an application-defined design.

Questions a decoded UUID can and cannot answer
A decode can showA decode cannot prove
Canonical text, version, variant, and field boundariesThat the identifier is absent from every other system
An embedded timestamp in versions 1, 6, or 7The time a business event or database record was created
A node field in versions 1 or 6Which machine generated the value without producer evidence
Nil, Max, legacy, and future-reserved layoutsWhether an application accepts or assigns meaning to them

A structurally valid UUID can still be a poor identifier. One sample does not reveal the quality of a random generator, the correctness of its clock, its collision handling, or the meaning of a custom payload. Treat decoded fields as clues about construction, then check the producer's specification when identity, ordering, privacy, or provenance matters.

How to Use This Tool:

Decode one identifier at a time and choose display settings for the question you are investigating.

  1. Paste a value into UUID token. The input may use uppercase or lowercase hexadecimal, canonical hyphens, surrounding braces, or a UUID URN.
  2. Choose Preferred representation for reusable text and Timestamp display for versions 1, 6, or 7. These choices change presentation, not the 128-bit value.
  3. Pick a Review context only when you need an additional database, forensic, or API note. Enable Strict RFC variant review when non-RFC compatibility layouts should fail an ingest check.
  4. Read Decoded fields for values and Bit allocation for field positions. If several non-empty lines were pasted, correct the input before relying on the result because only the first token is decoded.

Interpreting Results:

Start with the variant and version. The version field is meaningful only within the applicable variant layout, and reserved layouts need their own producer documentation.

  • RFC 9562 with variant bits 10xx permits the standard version interpretation shown below. NCS, Microsoft, and future-reserved variants are reported for inspection but are not converted into RFC semantics.
  • Nil UUID means all 128 bits are zero; Max UUID means all bits are one. Both are sentinel values, not ordinary generated identifiers.
  • A v1 or v6 node field whose multicast bit is clear may contain an IEEE 802 address. A set multicast bit is consistent with a randomized node value, but does not prove how it was generated.
  • A timestamp narrows a producer-time hypothesis. Confirm it against logs, database history, and clock evidence before treating it as event provenance.

Technical Details:

Normalization removes a case-insensitive UUID URN prefix, a matching pair of braces, and hyphens. Exactly 32 hexadecimal digits must remain. The normalized value is lowercase and regrouped into the canonical 8-4-4-4-12 form.

Rule Core:

The most significant bits of octet 8 select the variant. For the RFC layout, the four high bits of octet 6 select the version.

UUID variant prefix rules
Variant prefixLayoutReview meaning
0xxxNCS compatibilityLegacy reserved layout; strict RFC review fails
10xxRFC 9562Interpret the remaining fields by UUID version
110xMicrosoft compatibilityLegacy reserved layout; strict RFC review fails
111xFuture-reservedNo payload semantics are inferred; strict RFC review fails
UUID version families
VersionConstructionImportant limit
0Unused version fieldDo not infer payload semantics
1Gregorian time, clock sequence, and nodeTime and node material may reveal operational details
2DCE SecurityProducer context is required
3Name-based MD5Reproducibility depends on the exact namespace and name
4Random or pseudorandomOne UUID cannot demonstrate generator entropy
5Name-based SHA-1Reproducibility depends on the exact namespace and name
6Reordered Gregorian timeRetains clock sequence and node fields
7Unix time in milliseconds plus random or monotonic fieldsThe embedded time is generator time, not business-event proof
8Application-defined payloadRFC 9562 does not define the custom field meanings
9 to 15Future-reserved versionsNo field meanings are inferred

Transformation Core:

Field allocation changes with the version. Version 7 uses the first 48 bits as Unix milliseconds, bits 48 to 51 for version 7, bits 52 to 63 for rand_a, bits 64 to 65 for the RFC variant, and bits 66 to 127 for rand_b. Versions 1 and 6 instead assemble a 60-bit Gregorian timestamp and expose a 14-bit clock sequence plus a 48-bit node field.

Worked version 7 UUID decode path
Input portionDecoded fieldValue
017f22e279b0Bits 0 to 47Unix timestamp 1,645,557,742,000 ms
7Bits 48 to 51Version 7
cc3Bits 52 to 63rand_a
9 high bitsBits 64 to 6510, RFC 9562 variant
Remaining tailBits 66 to 127rand_b

Formula Core:

Version 7 stores Unix milliseconds directly. Versions 1 and 6 store 100-nanosecond ticks from the UUID Gregorian epoch; subtracting the RFC epoch offset and dividing by 10,000 converts those ticks to Unix milliseconds.

tUnix ms = TUUID 100 ns122192928000000000 10000
tv7 Unix ms=unsigned value of bits 0 to 47

Unix seconds are displayed by flooring Unix milliseconds divided by 1,000. UTC output is rendered to millisecond precision, so any 100-nanosecond detail present in v1 or v6 is not shown in that display form.

Accuracy and Privacy Notes:

Decoding happens locally in the browser. The result is deterministic for the first non-empty UUID token and the selected display options.

Time-based UUIDs can expose when a generator ran, and versions 1 or 6 can carry a node value consistent with a network hardware address. Avoid publishing decoded evidence when those details are sensitive. The decoder does not test uniqueness across a dataset, validate an application's schema, or assess the random generator that produced a v4 or v7 value.

References: