Universally Unique Identifier (UUID) Decoder
Decode a UUID into canonical text and inspect its version, variant, bit fields and embedded time with checks for sentinel or legacy layouts.
{{ summaryHeading }}
{{ summaryPrimary }}
{{ summaryLine }}
{{ variantBadge }}
{{ formatBadge }}
{{ report.preferred_uuid }}
| Field | Bits | Value | Meaning | Copy |
|---|---|---|---|---|
| {{ row.field }} | {{ row.bits }} | {{ row.value }} | {{ row.meaning }} |
{{ fieldsExportStatus }}
| Signal | Check | Evidence | Next step | Copy |
|---|---|---|---|---|
| {{ 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.
| A decode can show | A decode cannot prove |
|---|---|
| Canonical text, version, variant, and field boundaries | That the identifier is absent from every other system |
| An embedded timestamp in versions 1, 6, or 7 | The time a business event or database record was created |
| A node field in versions 1 or 6 | Which machine generated the value without producer evidence |
| Nil, Max, legacy, and future-reserved layouts | Whether 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.
- Paste a value into UUID token. The input may use uppercase or lowercase hexadecimal, canonical hyphens, surrounding braces, or a UUID URN.
- Choose Preferred representation for reusable text and Timestamp display for versions 1, 6, or 7. These choices change presentation, not the 128-bit value.
- 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.
- 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
10xxpermits 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.
| Variant prefix | Layout | Review meaning |
|---|---|---|
0xxx | NCS compatibility | Legacy reserved layout; strict RFC review fails |
10xx | RFC 9562 | Interpret the remaining fields by UUID version |
110x | Microsoft compatibility | Legacy reserved layout; strict RFC review fails |
111x | Future-reserved | No payload semantics are inferred; strict RFC review fails |
| Version | Construction | Important limit |
|---|---|---|
| 0 | Unused version field | Do not infer payload semantics |
| 1 | Gregorian time, clock sequence, and node | Time and node material may reveal operational details |
| 2 | DCE Security | Producer context is required |
| 3 | Name-based MD5 | Reproducibility depends on the exact namespace and name |
| 4 | Random or pseudorandom | One UUID cannot demonstrate generator entropy |
| 5 | Name-based SHA-1 | Reproducibility depends on the exact namespace and name |
| 6 | Reordered Gregorian time | Retains clock sequence and node fields |
| 7 | Unix time in milliseconds plus random or monotonic fields | The embedded time is generator time, not business-event proof |
| 8 | Application-defined payload | RFC 9562 does not define the custom field meanings |
| 9 to 15 | Future-reserved versions | No 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.
| Input portion | Decoded field | Value |
|---|---|---|
017f22e279b0 | Bits 0 to 47 | Unix timestamp 1,645,557,742,000 ms |
7 | Bits 48 to 51 | Version 7 |
cc3 | Bits 52 to 63 | rand_a |
9 high bits | Bits 64 to 65 | 10, RFC 9562 variant |
| Remaining tail | Bits 66 to 127 | rand_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.
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:
- RFC 9562: Universally Unique IDentifiers (UUIDs), RFC Editor, May 2024.
- UUID Registry, IANA.