UUID decoder

What is inside a UUID?

A UUID is 128 bits, usually written as 32 hexadecimal digits in five hyphenated groups. Most of those bits vary by version, but six of them never do: four spell out the version and two mark the variant. That is why every version 4 UUID has a literal 4 starting its third group, and why the fourth group almost always begins with 8, 9, a or b.

Those six bits are what this page reads. The version tells you how the UUID was made — from randomness, from a hashed name, or from a clock — and therefore what else you can learn from it. The variant tells you which specification's layout it follows, which matters because two of the four variants predate the standard everyone uses.

The current specification is RFC 9562, published in May 2024, and it replaced RFC 4122 outright. It added versions 6, 7 and 8 and the Max UUID, so a decoder written before then will not recognise a version 7 UUID at all — and version 7 is the one increasingly used for new database keys.

How to use it

1. Paste the UUID. Hyphenated, bare hex, wrapped in braces, or with a urn:uuid: prefix — all four forms are accepted, and case does not matter.
2. Read the version and variant. Each is explained rather than just named, including what it implies about where the bits came from. Versions new in RFC 9562 are marked.
3. Check whether there is a time in it. Versions 1, 6 and 7 encode an instant, and the tool decodes it exactly. Every other version carries none, and the tool says so rather than showing you a number.

The clock that starts in 1582

Version 1 UUIDs carry a 60-bit timestamp, and the specification defines it as a count of 100-nanosecond intervals since 00:00:00.00 on 15 October 1582 — the day the Gregorian calendar came into use. A UUID generated this morning is counting from the sixteenth century, in ten-millionths of a second.

This is not a quirk somebody noticed later; the RFC is openly critical of it. Explaining why version 7 exists, it calls that epoch uncommon and difficult to represent accurately in a standard number format, which is a fair complaint: 60 bits of hundred-nanosecond ticks does not fit in the floating point number most languages hand you by default. This page carries the count as an exact integer and converts once, at the end.

Version 6 is the same clock with the fields reordered so the most significant part comes first, which makes the UUIDs sort into time order as plain strings. Version 7 abandons the Gregorian epoch entirely and stores ordinary Unix milliseconds in the first 48 bits. All three of the specification's own example UUIDs encode the same instant, and decoding them here gives the same answer three times over.

Version 7 tells everyone when it was made

Version 7 is now the common recommendation for database primary keys, and the reason is real: because the timestamp leads, the identifiers sort by creation time, so they insert at the end of an index instead of scattering across it. That fixes a genuine performance problem that random version 4 keys cause.

What is said far less often is the other consequence. The creation time is not stored beside the identifier, it is the first 48 bits of the identifier, and there is no setting that turns it off. Anyone who sees a version 7 UUID knows the millisecond it was generated. If those identifiers appear in URLs, in API responses, in support tickets or in anything a customer can see, you have published your creation timestamps — and, given two of them, the interval between two events.

That is often harmless and occasionally is not: sequential-looking keys let an outsider estimate how many records you create per hour, and a leaked creation time can be enough to correlate an anonymous record with a known event. It is a reason to think about where the identifier travels, not a reason to avoid version 7 — but it should be a decision rather than a surprise.

Version 4, by contrast, has nothing in it. 122 of its 128 bits are random and the other six are the fixed version and variant markers, so a version 4 UUID reveals only that it is a version 4 UUID. If a decoder ever shows you a date for one, it has invented it.

What this does not tell you

It does not tell you whether the UUID is real. Any 32 hexadecimal digits with the right six bits in the right places will decode perfectly, whether or not anything ever generated it. The check is structural, not existential.

For version 1 it decodes the time but says nothing about the node field, which in the original design was the machine's network card address. That is precisely why version 1 fell out of favour for anything public, and reading it back is not a service worth offering.

Version 3 and version 5 are hashes of a name in a namespace, and hashes do not run backwards: the UUID is derived from the input, but the input cannot be recovered from the UUID. And version 8 is deliberately unspecified — the standard defines only its version and variant bits and says nothing about the rest, so there is nothing to decode beyond what this page already shows.

Why is it free?

It is bit-shifting on 128 bits, running in your browser. There is no lookup, no server and no account.

Nothing you paste is uploaded, stored or logged — which matters here, because a UUID from your own system is an identifier for one of your records. It never leaves the tab.