UUID Decoder
All processing happens in your browser. No data is sent to any server.
About this tool
What the decoder reads from a UUID
A UUID is 128 bits printed as 32 hexadecimal digits in the 8-4-4-4-12 grouping, and two of those digits are metadata rather than payload. The first digit of the third group is the version, which tells you how the remaining bits were produced. The first digit of the fourth group encodes the variant, where a value of 8, 9, A, or B marks the RFC 9562 layout that virtually every modern library emits; other values indicate the legacy NCS or Microsoft GUID layouts, or a reserved future format. Once the version is known, the decoder can interpret the rest. For version 1 and version 6 it reconstructs the 60-bit Gregorian timestamp counted in 100-nanosecond intervals since 15 October 1582, along with the clock sequence and the 48-bit node identifier, which is often a real network card MAC address. For version 7 it reads the leading 48 bits as a Unix millisecond timestamp. For versions 3, 4, and 5 there is no timestamp to extract: v4 is pure randomness and v3 and v5 are deterministic hashes of a namespace and a name, so the decoder reports the version and variant and shows the bit layout without inventing a creation time.
Which UUID version am I looking at
The version digit is the fastest way to identify a UUID, and it sits in a fixed position: the thirteenth hexadecimal digit, which is the first character of the third hyphen-separated group. A UUID reading 018f3e5a-7c31-7c8e-... has a 7 there and is therefore version 7. In practice the distribution is lopsided. Version 4 dominates existing systems because it is the default in most standard libraries, and its randomness makes it trivially safe to generate anywhere without coordination. Version 1 shows up in older enterprise systems and in Cassandra timeuuid columns, and it is worth flagging in a security review because the node field can leak the MAC address of the machine that generated it. Version 7 is the current recommendation for new work: it keeps the standard UUID text format and ecosystem support while placing a millisecond timestamp in the most significant bits, so IDs sort chronologically and database B-tree indexes stay compact instead of fragmenting the way random v4 keys do. Version 6 is a transitional reordering of version 1 offered for systems that need v1 semantics with v7 sort behaviour.
Frequently Asked Questions
Can you get the timestamp out of a UUID?
It depends entirely on the version, and the decoder tells you which one you have. Version 1 and version 6 embed a 60-bit timestamp counting 100-nanosecond intervals since 15 October 1582, the date the Gregorian calendar was adopted, which the decoder converts to a normal date and time. Version 7 embeds a 48-bit count of milliseconds since the Unix epoch in its leading bits, which is both easier to read and easier to sort. Version 4 contains no timestamp at all: 122 of its 128 bits are random, so there is nothing to extract and any tool claiming to recover a creation time from a v4 UUID is guessing. Versions 3 and 5 are equally timestamp-free because they are deterministic hashes, with v3 using MD5 and v5 using SHA-1 over a namespace UUID plus a name. That determinism is their purpose: the same namespace and name always produce the same UUID, which is useful for deriving stable IDs from existing identifiers such as a URL or a domain name, but it means the value carries no information about when it was created.
What does the variant field mean?
The variant occupies the two or three most significant bits of the ninth byte, which is the first hexadecimal digit of the fourth group in the printed form. When that digit is 8, 9, A, or B, the UUID follows the RFC 9562 layout, and this covers essentially everything generated by a current library. A leading digit of 0 through 7 indicates the reserved NCS backward-compatibility layout from Apollo Network Computing System. A digit of C or D indicates the Microsoft GUID layout, which stores the first three fields in little-endian byte order; this is why the same GUID can appear byte-swapped when it crosses between a Windows API and a database that stores UUIDs big-endian. A digit of E or F is reserved for future definition. The variant matters when you are decoding by hand or writing a parser, because getting it wrong means reading the version digit and timestamp fields at the wrong offsets and producing a plausible but entirely fictional result.
Is a UUID with a MAC address a security problem?
It can be, and it is worth knowing when your IDs are version 1. The node field of a v1 UUID is 48 bits that the specification says should be the IEEE 802 MAC address of the generating machine, and many implementations do exactly that. Exposing v1 UUIDs in URLs, API responses, or logs therefore publishes a stable hardware fingerprint for your servers, which helps an attacker correlate requests to specific machines and map your infrastructure. The timestamp compounds this: because v1 timestamps have 100-nanosecond resolution and the clock sequence changes only on clock regression, an attacker who sees two v1 UUIDs can often infer how many IDs were generated in between, which leaks throughput and sometimes lets them guess neighbouring identifiers. The specification does permit a random node value with the multicast bit set instead of a real MAC, and some libraries default to that, so the presence of v1 does not prove a leak. If you control the generator and need time-ordered IDs, version 7 gives you the sortability without the hardware identity.