Universally Unique Identifier (UUID) Decoder

V{{ version_num }} {{ variant_bits }}

Ignored {{ ignoredExtraLines }} extra {{ ignoredExtraLines === 1 ? 'line' : 'lines' }}. UUID decoder processes one token at a time.

UUID token:

Paste one UUID token, for example 018f4f4b-ff15-7b9a-bf4f-5f2cdbf3ea91.

Preferred representation:

Choose canonical, uppercase, braced, URN, or 32-hex compact form.

Timestamp display:

Options: UTC ISO, local ISO, Unix seconds, or Unix milliseconds.

Clock sequence display:

Choose decimal, hex, or both when the decoded family defines a full clock sequence.

Guidance profile:

Pick the review context; UUID validation and decoded fields stay the same.

Strict variant mode:

Enable for ingest validation; leave off when inspecting Nil, Max, or legacy variants.

Field	Value	Copy
{{ row.label }}	{{ row.value }}

Segment	Hex	Binary	Detail	Copy
{{ segment.label }}	{{ segment.hex }}	{{ segment.binary }}	{{ segment.detail }}

Track	Recommendation	Copy
{{ row.track }}	{{ row.note }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A UUID is a 128-bit identifier that often outlives the screen where it was created. It shows up in database keys, API payloads, filesystem records, log lines, queue messages, support tickets, and audit notes. The same value may be written with lowercase letters, uppercase letters, hyphens, braces, a urn:uuid: prefix, or no separators, so the first question is whether the text normalizes to the same 32 hexadecimal digits.

The shape is only the beginning. UUIDs carry marker bits that define how the rest of the value should be read. The version marker says whether the identifier is time-based, name-based, random, Unix-time-based, or custom. The variant marker sets the broad compatibility layout before the version is interpreted. A UUID that looks valid but has a legacy or reserved variant can behave poorly at strict ingest boundaries.

Different UUID families answer different questions. Version 4 is entropy-first and has no embedded time. Versions 1 and 6 carry a Gregorian UUID timestamp, a clock sequence, and a node-compatible tail. Version 7 carries a Unix millisecond timestamp plus random payload, which makes it popular for ordered database indexes. Versions 3 and 5 are name-based hashes, while version 8 leaves most payload meaning to the producing system.

Text formatting can be normalized without changing the identifier.
Version and variant evidence can be decoded from fixed bit positions.
Timestamps inside UUIDs are useful clues, not a complete event history.
Node-compatible tails can be randomized, locally assigned, or privacy-sensitive.
Nil and Max UUIDs are boundary values, not ordinary object identifiers.

Decoding a UUID is most useful when it narrows the next check. It can tell you how an identifier is structured, whether it fits a strict RFC-style layout, and which fields deserve caution, but it cannot prove that the UUID exists in a database or that the generator produced enough uniqueness.

How to Use This Tool:

Paste one UUID token, choose the display options that match your review, and compare the decoded evidence before sending it to a ticket, audit note, ingest rule, or storage decision.

Paste one value into UUID token. Canonical, uppercase, brace-wrapped, URN, and compact 32-hex forms are accepted. If you paste multiple non-empty lines, the first token is decoded and an ignored-lines warning appears.
Open Advanced when presentation matters. Preferred representation changes which canonical, uppercase, braced, URN, or compact form is emphasized without changing the 128-bit identifier.
Set Timestamp display for time-bearing versions. UTC is best for cross-system evidence, local time helps human incident notes, and Unix seconds or milliseconds match many logs and database fields.
Only versions 1, 2, 6, and 7 expose timestamp material here. Other versions show that no standard timestamp is available.
Use Clock sequence display for version 1 and version 6 values when decimal, hexadecimal, or both forms are useful for comparison.
Choose a Guidance profile for the review context. Storage/indexing, forensics/audit, and interoperability/API modes change the Routing Notes, not the decoded fields.
Enable Strict variant mode for ingest validation that should accept only mainstream Variant 1 UUIDs. Leave it off when inspecting Nil, Max, Microsoft GUID layout space, old compatibility patterns, or future-reserved variants.
Strict variant mode rejects UUID-shaped values outside the 10xx variant, including Nil and Max boundary values.
Read Decoded Ledger first, then use Bit Lanes for segment evidence, UUID Signal Map for bit allocation, Routing Notes for practical cautions, and JSON for structured handoff.
If the error says UUIDs require exactly 32 hexadecimal digits, remove surrounding log text, punctuation, or unrelated tokens and retry with one UUID only.

Interpreting Results:

Version identifies the UUID family. Version 7 and version 6 are reported as index-friendly because their time material improves chronological locality. Version 4 is random-style and has no embedded time. Versions 3 and 5 are name-based hash values, and version 8 needs producer documentation before its payload can be understood.

Variant is a compatibility boundary. Variant 1 is the mainstream RFC 4122 and RFC 9562 layout. Variant 0, Variant 2, and Variant 3 can still be UUID-shaped, but strict systems should not treat them as ordinary Variant 1 values without an explicit reason.

UUID decoded result fields and interpretation limits
Result field	Useful meaning	Limit
Timestamp	Embedded time material for versions 1, 2, 6, or 7.	May reflect generator time, queue time, import time, or a skewed clock rather than business event time.
Clock sequence	A 14-bit field for version 1 and version 6 values.	Helpful structural evidence, not a complete collision or generator-health test.
Node flags	Locally administered and multicast flags from node-compatible tails.	A node tail is not verified hardware identity and may be randomized.
Random segment A/B	Version 7 random payload separated from timestamp and marker bits.	Shows field allocation, not randomness quality.
Nil or Max UUID	Boundary values often used as empty sentinels or upper-bound markers.	Should be reviewed before being counted as real assigned identifiers.

A valid UUID shape does not prove uniqueness, database existence, record ownership, account status, or generator quality. Use the decoded structure as evidence that guides the next system-specific check.

Technical Details:

A UUID contains 16 bytes. The common text form prints those bytes as five hexadecimal groups in the 8-4-4-4-12 pattern. The high 4 bits of byte 6 hold the version, and the high bits of byte 8 hold the variant. Once those marker bits are known, the remaining bits can be labeled according to the UUID family.

Normalization removes acceptable wrappers and separators before decoding. After that, the decoder reads exactly 32 hexadecimal digits into bytes, recognizes Nil and Max boundary values, classifies the variant pattern, and applies family-specific field labels for timestamps, hashes, random payload, DCE fields, node tails, or custom payload.

Normalization and Marker Rules:

UUID normalization and marker decoding rules
Rule	How it is read	Result meaning
Text form	Optional URN prefix, braces, hyphens, whitespace, and case differences are normalized.	The same identifier can be shown as canonical, uppercase, braced, URN, or compact text.
Length and alphabet	The normalized token must contain exactly 32 hexadecimal digits.	Extra log text, copied punctuation, or missing digits prevents a decode.
Version	The high nibble of byte 6 is read as a number from 0 to 15.	Versions 1 through 8 receive known family labels; other values remain unrecognized or future-reserved.
Variant	The high bits of byte 8 are classified as `0xxx`, `10xx`, `110x`, or `111x`.	The pattern identifies obsolete NCS, mainstream RFC, Microsoft GUID, or reserved layout space.
Sentinels	All zero bits and all one bits are recognized separately.	Nil and Max UUIDs should be interpreted as boundary values before ordinary assignment assumptions.

Version Families:

UUID version family reference
Version	Family	Decoded evidence	Main caution
1	Gregorian time-based	60-bit timestamp, clock sequence, node tail	Node-compatible tails can expose or imitate host-style identity.
2	DCE security	Partial Gregorian timestamp, local identifier, local domain, node tail	The local identifier replaces the low 32 timestamp bits.
3	Name-based MD5	Hash payload with version and variant markers	The namespace and name cannot be recovered from the UUID alone.
4	Random or pseudorandom	Random payload with version and variant markers	Structure does not test the quality of the random source.
5	Name-based SHA-1	Hash payload with version and variant markers	The original namespace and name remain external evidence.
6	Reordered Gregorian time	60-bit timestamp ordered for sorting, clock sequence, node tail	Sortable form still carries time-based-family privacy concerns.
7	Unix time plus randomness	48-bit Unix millisecond timestamp, 12-bit random A, 62-bit random B	Timestamp evidence should be compared with record timestamps.
8	Custom	Application-defined payload	Only the producing system can define the payload semantics.

Timestamp Formula Core:

Versions 1, 2, and 6 use the Gregorian UUID epoch, counted in 100-nanosecond ticks since 15 October 1582. Unix milliseconds subtract the UUID epoch offset and divide by 10,000.

t_{unix_ms} = \frac{T_{uuid_100ns} - 0x01B21DD213814000}{10000}

Version 7 stores Unix milliseconds directly in the first 48 bits. The remaining version, variant, and random fields explain the rest of the 128-bit value.

t_{unix_ms} = first 48 bits

The signal map reports each decoded segment as a share of the full UUID.

share = \frac{segment bits}{128} \times 100 %

Worked Decode Path:

Example UUID decode path for a version 7 identifier
Step	Example	Decoded meaning
Normalize	`018f4f4b-ff15-7b9a-bf4f-5f2cdbf3ea91`	The token already has canonical lowercase hyphenated form.
Read markers	Version `7`, variant `10xx`	The mainstream RFC layout applies, and the UUID is a Unix-time family value.
Extract time	`1715022331669` Unix milliseconds	The embedded timestamp is `2024-05-06T19:05:31.669Z` in UTC.
Read payload	`b9a` and `3f4f5f2cdbf3ea91`	Random segment A and 62-bit random segment B are separated from marker bits.

Accuracy and Privacy Notes:

Decoding is deterministic and runs in the current browser session after the page loads. UUIDs can still be sensitive when they expose record identity, timestamps, or node-compatible tails, so avoid putting confidential identifiers in shared screenshots, exported files, or public URLs.

Structural validity does not prove that a UUID exists in a database or belongs to an active object.
A version 4 UUID can be well formed even when the producing system used weak randomness.
A decoded timestamp can differ from business event time when IDs are generated ahead of use, imported, rewritten, or produced on a skewed clock.
A node tail is decoded field evidence, not verified device identity.
Routing notes are guidance from the decoded structure and selected review context, not policy by themselves.

Worked Examples:

Checking a new database key

018f4f4b-ff15-7b9a-bf4f-5f2cdbf3ea91 reports Version 7, Variant 1, a UTC timestamp of 2024-05-06T19:05:31.669Z, and an index-friendly posture. That supports an indexing review, but a created_at column is still better evidence for business time.

Reviewing a legacy time-based value

A version 1 or version 6 UUID shows Timestamp, Clock sequence, Node, and Node flags. If the node flags show a globally unique unicast tail, treat that field as privacy-sensitive evidence unless you know the generator randomized or masked it.

Catching a boundary value

00000000-0000-0000-0000-000000000000 is marked as a Nil UUID token. The useful conclusion is not uniqueness. It usually points to an empty association, missing identifier, default value, or placeholder. With Strict variant mode enabled, the same value is rejected because it is not Variant 1.

Fixing copied log text

If a full log line triggers the "exactly 32 hexadecimal digits" error, isolate the UUID first. Paste only the token, then verify Canonical, Version, and Variant bits before copying JSON, ledger rows, or routing notes into a ticket.

FAQ:

Do uppercase, braced, URN, and no-dash UUIDs mean different values?

No. They are different text representations of the same 128-bit value when the 32 hexadecimal digits match. Use Preferred representation when a target system expects a specific text form.

Why does a valid UUID have no timestamp?

Only versions 1, 2, 6, and 7 carry timestamp material here. Versions 3, 4, 5, and 8 do not provide a standard timestamp field that can be decoded from the UUID alone.

Does a version 7 UUID prove when a record was created?

No. It exposes a Unix millisecond timestamp embedded in the identifier. Compare the decoded Timestamp with application logs, database timestamps, or ingest records before treating it as creation time.

What does strict variant mode reject?

It rejects UUID-shaped values whose variant is not Variant 1. That includes Nil, Max, older compatibility patterns, Microsoft GUID layout space, and future-reserved patterns.

Can the decoder tell if a UUID exists in a database?

No. It decodes structure only. A UUID can be well formed and still not correspond to an active record, account, request, or object in any specific system.

Glossary:

UUID: A 128-bit identifier commonly displayed as 32 hexadecimal digits with hyphens.
Version: The 4-bit family marker that identifies time-based, random, name-based, custom, or unrecognized UUID layouts.
Variant: The high-bit pattern that selects the broad compatibility layout before version-specific fields are read.
Clock sequence: A 14-bit value used by versions 1 and 6 to reduce collision risk around clock changes and rapid generation.
Node: The final 48-bit field in node-compatible UUID layouts, useful as structural evidence but not proof of a physical device.
DCE: Distributed Computing Environment, the source of version 2 local identifier and local domain fields.
Nil UUID: The all-zero UUID, commonly used as an empty, uninitialized, or missing-value sentinel.
Max UUID: The all-one UUID, often used as a high boundary marker in range logic.

References:

RFC 9562: Universally Unique IDentifiers (UUIDs), RFC Editor, May 2024.
UUID Registry, IANA.
RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace, RFC Editor, July 2005.