Developer tools · UUID generator
Reading a UUID by Hand: Where the Version and Variant Bits Live
· How it works
uuid cryptography browser-apis
Two hex characters in every UUID tell you which version produced it and which variant layout it follows. Learn to read them at a glance and to know what they cannot tell you.
Which system made this ID? — the log-forensics question that the version nibble can answer
A UUID string has 36 characters: thirty-two hexadecimal digits and four hyphens in the positions 8-4-4-4-12. Two characters in every UUID—appearing at positions 14 and 19—encode metadata: the version field tells you which algorithm generated the ID, and the variant field tells you which standard layout it follows. Reading these two characters without tools is the log forensics skill: you spot a UUID in a database dump or error message and immediately know whether it is a v1 timestamp (which leaks creation time), a v4 random value (which was generated from a CSPRNG), or something else. The version number occupies bits 48–51 of the UUID, which maps to the first hexadecimal character of the third group.
The 128-bit layout in five groups — how 8-4-4-4-12 maps onto bytes and why the groups are historical, not functional
For the string xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx, the character at position 14 is the version. RFC 9562 defines versions 1 through 8: v1 is Gregorian-time-based and leaks creation time; v4 is random; v7 is Unix-time-based and sortable. Version 0, 9, and higher are reserved or unused. If you see a v1 UUID, you know the time and hardware address were mixed in; if you see v4, the ID is random bytes with version bits set; if you see v7, it sorts by creation time. The version is not optional; every correctly formed UUID has one. The variant field occupies bits 64–65 of the UUID, the two most significant bits of octet 8.
The version nibble — the first character of the third group, what 1 through 8 mean, and what a 0 or 9 there indicates
In the text representation xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx, the first character of the fourth group (position 19) encodes the variant. For RFC 9562 variant (the standard in modern use), this character must be 8, 9, a, or b—the hexadecimal representations of 1000, 1001, 1010, and 1011 in binary. Any other character (0–7, c–f) indicates a different variant: 0–7 are NCS backward compatibility; c–d are Microsoft legacy GUIDs with little-endian byte order; e–f are reserved. When you read position 19 and see 8, 9, a, or b, you are looking at an RFC 9562 UUID. Any other value means the bytes follow a different interpretation. The 128-bit layout divides into octets 0–15, but the text format separates them by groups for readability, not function.
The variant field — why the first character of the fourth group is 8, 9, a or b for RFC UUIDs, and what c/d (Microsoft legacy) or 0–7 (NCS) signal
The five groups represent historical field boundaries: the first three fields contain the timestamp and version in v1 UUIDs, the fourth field holds the clock sequence and variant, the fifth field holds the node identifier. Version 4 and later UUID versions do not use these field names, but the same bit positions still carry the version and variant. Reading a v4 UUID means accepting that most of the 128 bits are random payload, but two of them—at positions 14 and 19 in text—are fixed by standard. Those fixed bits prove the ID is a v4 and RFC-variant. The nil UUID is 00000000-0000-0000-0000-000000000000, all zeros, and carries no version at all. The max UUID is ffffffff-ffff-ffff-ffff-ffffffffffff, all f characters, and is also reserved and unversioned.
Worked example — decoding three sample identifiers character by character, including a v4 and a v7
Every other well-formed UUID has a version in the third group and a variant in the fourth. Test yourself with three sample IDs: 123e4567-e89b-12d3-a456-426614174000 (v1, variant RFC because position 19 is a); 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 (v4, variant RFC because position 19 is 8); 018f0c2e-1b5a-7c3d-9e4f-5a6b7c8d9e0f (v7, variant RFC because position 19 is 9). The ToolAcre inspector confirms your reading. A format check cannot tell you that an ID is unique, exists in your database, or was generated securely. Version v1 uses time and hardware as inputs, so identical v1 UUIDs from different machines mean clock skew or synchronization issues. Version v4 is random, so a duplicate v4 UUID means either broken randomness or an astronomically unlikely collision (roughly one per 2. 7 trillion UUIDs with sound randomness).
Nil and Max — the two all-zero and all-F values that carry no version at all
A version 0 or 9 means the string is not a valid UUID at all. Reading the version and variant is the first step in understanding what an ID is; checking whether it exists or is unique is the second and third steps, done by your database and business logic. Understanding bit positions helps debug data migrations. When importing UUIDs from legacy systems, some tools export variant fields that do not match the RFC 9562 standard. A variant field of c or d indicates a Microsoft GUID in little-endian byte order. These GUIDs are valid identifiers within Microsoft systems but do not interoperate with RFC 9562 UUIDs without byte-order conversion. Reading position 19 tells you immediately which system generated the ID. If you see 8, 9, a, or b, you have an RFC standard UUID.
What a format check cannot tell you — that the ID exists in your database, that it was generated securely, or that it is unique
If you see c or d, you have a Microsoft GUID. If you see any other character, the identifier is malformed or from an obscure system. The ToolAcre generator always produces RFC 9562 UUIDs with position 19 as one of 8, 9, a, or b. The three-bit version field encodes seven possible values (1–7; version 0 and 8 have special meanings). Version 1 is Gregorian timestamp, version 3 is MD5-based namespace, version 4 is random, version 5 is SHA-1-based namespace, version 6 is Unix-timestamp-based (proposed), version 7 is Unix-timestamp-based sortable (standardized in RFC 9562), version 8 is reserved for custom formats. Reading the position-14 character immediately tells you which algorithm was used. If you are debugging UUID collisions or unexpected sorts, the version number is your first clue. ToolAcre generates v4 UUIDs exclusively from crypto.
Takeaway: two characters, a lot of context — use the ToolAcre well-formed check to confirm a string parses, then read the version nibble yourself
getRandomValues; every UUID it produces has a 4 at position 14. Parsing UUID structure by hand is a useful skill for debugging complex systems where tools are not available. In a production incident, you might need to read UUIDs from a database dump, error log, or cache without running a special tool. You look for position 14 to identify the version (does it leak time? is it random? is it sortable? ). You look for position 19 to identify the variant (is it RFC standard? is it a Microsoft GUID? is it reserved? ). These two characters, out of 36 total, carry the metadata. The remaining 34 characters are payload: timestamp or random bytes or other algorithm-specific data. Knowing what the payload represents helps you understand the ID's role in your system.