Reading a UUID: How to Detect Its Version and Variant by Eye
A practical guide to inspecting a UUID — read its version and variant straight from the 8-4-4-4-12 layout, tell v1 from v4 from v7, and pull the timestamp out of v1 and v7.
Reading a UUID: How to Detect Its Version and Variant by Eye
A UUID looks like a wall of hex, but it is not random noise even when the contents are. Once you know where to look, a single 36-character string tells you which algorithm produced it, which byte-order family it belongs to, and — for two of the versions — exactly when it was created. You do not need a library to read most of this. You need to know which two characters carry the meaning.
This guide walks through that layout: the 8-4-4-4-12 shape, the version nibble, the variant bits, and how to extract a real timestamp from a v1 or v7 UUID. By the end you will be able to glance at an ID and say "that is a time-ordered v7 minted last Tuesday" without running anything.
The 8-4-4-4-12 layout, byte by byte
A UUID is 128 bits — 16 bytes — written as 32 hexadecimal digits. The canonical form groups those digits into five blocks separated by hyphens: 8, then 4, then 4, then 4, then 12. So c232ab00-9414-11ec-b3c8-9e6bdeced846 is the same value as the bare string c232ab009414 11ecb3c89e6bdeced846 with the hyphens stripped. The hyphens are decoration; tools that parse UUIDs trim whitespace, lowercase the text, and accept either form.
Each pair of hex digits is one byte. That mapping matters because the two pieces of metadata you care about live at fixed byte positions, not fixed character positions you might guess at. Here is the concrete rule worth memorizing: a UUID is 32 hex digits in an 8-4-4-4-12 pattern; the first digit of the third group is the version (1, 4, 7, and so on), and the high bits of the fourth group encode the variant. So you can read what kind it is straight off the string, and for v1 and v7 you can pull the timestamp out of the leading bytes.
Where the version lives
The version is the 13th hex character of the whole string — equivalently, the first digit of the third group. In byte terms it is the high four bits of byte 6.
Take 0190b5c2-3a40-7000-8000-000000000000. The third group is 7000, and its first digit is 7, so this is a v7. Swap in 0190ae99-a800-4000-8000-000000000000: the third group starts with 4, so it is a v4. The same nibble reads 1, 3, or 5 for those versions. Nothing else in the string is consulted to determine the version — just that one character.
What each version means in practice:
- v1 — time-based. Built from a 60-bit timestamp plus a clock sequence and a node identifier that was historically the machine's MAC address. It leaks both when and, potentially, where it was created.
- v3 / v5 — name-based hashes. A namespace and a name hashed with MD5 (v3) or SHA-1 (v5). Deterministic: the same input always yields the same UUID. No timestamp is recoverable because there never was one.
- v4 — random. 122 bits from a cryptographic random source, with only the version and variant fixed. No embedded time, machine, or counter. This is the default in most languages.
- v7 — time-ordered. A 48-bit Unix-millisecond timestamp in the leading bytes followed by random bits. Sortable by creation order, which is why databases like it for primary keys — writes stay near the right edge of the B-tree instead of scattering.
Where the variant lives
The variant is a separate field from the version, and people mix them up constantly. It is the 17th hex character — the first digit of the fourth group, the high bits of byte 8. It does not tell you the algorithm; it tells you the byte-order family the layout follows.
Read that character:
8,9,a, orb→ the RFC 4122 / 9562 variant, which is what nearly everything modern produces.cord→ a Microsoft GUID, which stores some fields little-endian. This is the rarer case worth catching when a.NETservice hands you an ID.0through7→ the legacy NCS layout.
A v4 and a v7 can carry the same variant; the version nibble is what separates them. Treating the variant as the version is one of the most common mistakes, and it is exactly the kind of thing the UUID Inspector flags side by side so you never confuse the two.
A worked example
Let me read c232ab00-9414-11ec-b3c8-9e6bdeced846 the way I do it at my desk, by eye, before pasting anything anywhere.
Third group is 11ec. First digit: 1. So this is a v1, time-based. Fourth group is b3c8. First digit: b, which falls in the 8–b range, so it is the RFC 4122 variant. Already I know it is an old-style time-based UUID with a real timestamp and a node baked in.
Now the timestamp. A v1 stores a 60-bit count of 100-nanosecond intervals since the Gregorian epoch of 1582-10-15. The count is spread across time_low (the first group), time_mid (the second), and the low 12 bits of the third group. Reassemble those, multiply by 100 nanoseconds, add the offset between 1582 and the Unix epoch, and c232ab00-9414-11ec-b3c8-9e6bdeced846 resolves to 2022-02-22T19:22:22Z. The last group, 9e6bdeced846, is the 48-bit node. The reassembly is fiddly to do in your head, which is the one part I do hand off to a tool — but the version and variant I read straight off the string.
For a v7 the math is friendlier: the first six bytes are a big-endian Unix-millisecond timestamp, so 0190b5c2-3a40-7000-… has its time sitting right there in 0190b5c23a40, no epoch gymnastics required.
Validating the format
Before any of the above is meaningful, the string has to actually be a UUID. The check is mechanical: after trimming and lowercasing, you need exactly 32 hexadecimal digits arranged as 8-4-4-4-12 (or the bare 32-character run). Anything else — a stray letter outside 0-9a-f, the wrong group lengths, a truncated paste — should be reported as invalid rather than silently guessed at.
Two values are valid but special. The Nil UUID, 00000000-0000-0000-0000-000000000000, is all zeros and used as an empty placeholder the way null is used elsewhere. The Max UUID, ffffffff-ffff-ffff-ffff-ffffffffffff, is defined by RFC 9562 as the largest possible value, handy as an upper bound in range scans. Both pass validation but carry no version or variant meaning, so they deserve a separate flag.
When you need to read a lot of them
Reading one UUID by eye is a party trick. Reading the version and variant, decoding a v1 or v7 timestamp to both UTC and your local time, and laying out every hex field at once is what the UUID Inspector does in a single paste, entirely in your browser. If you are going the other direction and need to mint IDs, the UUID Generator produces v4 by default, and once you have a v7 timestamp in hand the Timestamp Converter turns those Unix milliseconds into any format you need.
The short version to carry around: 8-4-4-4-12, first digit of group three is the version, first digit of group four is the variant, and v1 and v7 are the only ones hiding a clock. Everything else follows from those four facts.
Made by Toolora · Updated 2026-06-13