By the Withuse team · Updated
What a UUID will and will not tell you
A UUID is 128 bits, and almost all of them are opaque on purpose. Only six bits are structural: four for the version and two to four for the variant. Everything else means whatever the version says it means, so decoding is really a two-step process — establish the version first, then interpret the remaining bytes under that version's rules. Read them in the wrong order and you get confident nonsense, which is how tools end up reporting a "creation date" for random v4 values.
That is also why the byte map above redraws itself for each version. The same 16 bytes are a timestamp scattered across three fields in v1, a contiguous big-endian millisecond counter in v7, and undifferentiated random padding in v4. There is no universal layout to memorise, only a per-version one.
Recovering the creation time
Three versions carry a clock. Version 7 is the easy one: its first 48 bits are a plain count of milliseconds since the Unix epoch, so reading the timestamp is a single hexadecimal conversion of the leading twelve digits. Versions 1 and 6 use the Gregorian epoch of 15 October 1582 and count in 100-nanosecond intervals, which means the raw value has to be reduced by 122,192,928,000,000,000 ticks before it becomes a Unix time. Version 1 additionally splits that counter into three fields stored least-significant part first, while version 6 keeps the identical bits but reorders them so the value sorts chronologically — the reason v6 exists at all.
The practical consequence is a privacy one. If your identifiers are v1, v6 or v7, anyone holding one knows when the underlying record was created, to the millisecond or better. That is usually harmless for an internal primary key and occasionally not harmless at all for a public URL, where it exposes signup times, order volumes, or the gap between two events. Our comparison of v4 and v7 weighs that leak against the indexing benefit that motivates v7 in the first place.
Reading the variant, not just the version
The variant digit is the check that gets skipped, and skipping it is how malformed values slip through validation. A truncated or hand-edited string can easily carry a 4 in the version position while its variant bits fall outside the RFC range, and a shape-only regex will wave it through. Checking both positions costs nothing and rejects a whole class of bad input; our UUID regex patterns page gives expressions that enforce it, and the decoder above flags any non-RFC variant it sees.
When there is nothing to decode
Versions 3 and 5 are hashes, so they are one-way by construction. You cannot recover the namespace and name that produced one; you can only confirm a suspected input by hashing it again and comparing. Version 4 has nothing behind it at all — 122 random bits and six structural ones. Version 8 is deliberately open, meaning its layout is whatever the system that produced it decided, so no general decoder can interpret it. The Nil and Max UUIDs are constants rather than generated values, and the decoder labels them as such rather than pretending to parse them. For the full 8-4-4-4-12 anatomy behind all of this, see how long a UUID is and how it is structured.
Frequently asked questions
How do I check what version a UUID is?
Read the 13th hexadecimal digit — the first character of the third group. In 018e2b0f-6a40-7abc-8def-1234567890ab that digit is 7, so the value is a v7 UUID. The position is fixed by RFC 9562 and never moves, which is why a four-character glance is enough and no library is required. Do not infer the version from how the value looks: a v4 UUID and a v7 UUID are both 36 characters of hex, and people routinely mistake one for the other. The paste box above reads that digit for you and also checks the variant, because a value can carry a plausible version digit while still not being an RFC-conformant UUID at all.
Can you extract the timestamp from a UUID?
Only from versions 1, 6 and 7, and the decoder above does it for all three. A v7 UUID stores a 48-bit count of milliseconds since 1970-01-01 in its leading 12 hex digits, so the conversion is a single base-16 read. Versions 1 and 6 store a 60-bit count of 100-nanosecond intervals since 1582-10-15, the Gregorian reform date, which has to be shifted by 122,192,928,000,000,000 ticks to reach the Unix epoch. Version 1 scatters that counter across three separate fields in least-significant-first order, while version 6 rearranges the same bits into sortable order. Versions 3, 4, 5 and 8 contain no timestamp at all, so there is nothing to extract.
Can a UUID be decoded back to the original data?
No, and that is by design for every version. A v3 or v5 UUID is a truncated MD5 or SHA-1 digest of a namespace plus a name, and a hash cannot be run backwards — you can only confirm a guess by hashing it again and comparing. For example, 886313e1-3b8a-5372-9b90-0c9aee199e5d is the v5 UUID of the DNS namespace and the name python.org, which is verifiable by recomputation but not recoverable from the digits alone. A v4 UUID has nothing behind it to recover, since 122 of its 128 bits are random. Version 8 is worse still for a decoder, because RFC 9562 leaves its layout entirely to whoever generates it. Only the structural metadata decodes: version, variant, and the timestamp and node fields where the version defines them.
What is the variant digit and why does it matter?
The 17th hex digit encodes the variant, which says which specification governs the layout, and it is the check most people skip. Values 8 through b mean RFC 9562, the modern standard. Values 0 through 7 mean the legacy NCS Apollo scheme, c and d mean Microsoft's COM/DCE layout, and e or f are reserved. This matters because the version digit alone can lie: a hand-written or truncated string may carry a 4 in the version position while its variant bits are wrong, so it is not a valid v4 UUID even though a naive regex accepts it. The decoder above flags any non-RFC variant, and our guide to UUID regex patterns shows how to enforce both digits in validation.
Does a v1 UUID really contain a MAC address?
Often, yes — the last 12 hex digits are the node field, and the original specification filled it with the generating machine's network card address. That makes a v1 UUID a small information leak: it can reveal the hardware that created a record and, combined with the embedded timestamp, when. RFC 9562 permits a random node instead, and implementations that take that route set the multicast bit, the lowest bit of the first octet, so a generated node can never be confused with a real address. The decoder above reports which case you are looking at. If the node is unicast, treat the value as identifying a machine and avoid exposing it publicly.
References
Need to create UUIDs rather than read them? Use the free UUID generator for v1, v3, v4, v5 and v7 in bulk. Related: UUID v7 and its timestamp · UUID v1 and the node field