Interactive UUID Decoder
Visualize and understand the structure of any UUID.
Identify the version, timestamp, variant, and random components. How does it work?
Understanding UUID Versions & Variants
UUID Variants
The Variant field determines the overall layout of the UUID. While there are historical variants (like NCS and Microsoft GUIDs), the vast majority of UUIDs used today follow RFC 4122 / RFC 9562 (Variant 1).
Variant 1 (RFC 4122) is characterized by the bit pattern 10xx in the variant position. This ensures that the UUID allows for different "Versions" (like v1, v4, v7) to coexist while maintaining a consistent structure for parsers.
Why do I see 8, 9, a, or b?
The pattern 10xx covers binary values from 1000 to 1011. In hexadecimal, these correspond exactly to 8, 9, A, and B. If the 17th character of your UUID is one of these, it's a standard variant.
Other Variants:
- NCS (Variant 0): Legacy format for Apollo Network Computing System. Obsolete.
- Microsoft (Variant 2): Historically used for Microsoft COM/DCOM GUIDs.
- Reserved (Variant 3): Reserved for future definition.
Common UUID Versions
UUID v4: Random
The most popular version. It uses 122 random bits to ensure uniqueness. The probability of collision is astronomically low, making it perfect for generating IDs without coordination.
UUID v1: Time-based + MAC
Uses the current time and the machine's MAC address. This guarantees uniqueness per machine but reveals the time of creation and the machine identity (privacy concern).
UUID v7: Time-ordered (Modern)
The modern standard. It combines a 48-bit Unix timestamp with random bits. Crucially, the timestamp is at the start, making UUID v7s sortable by time (like KSUID or ULID). Excellent for databases.
UUID v3 & v5: Name-based (MD5 / SHA-1)
Generated by hashing a "namespace" UUID and a "name" string. They are deterministic: the same name and namespace always produce the same UUID. v3 uses MD5 (legacy), while v5 uses SHA-1 (preferred).
UUID v6: Reordered Time
An attempt to fix v1 sorting by rearranging the timestamp fields. Superseded by v7 but useful for backward compatibility with v1 systems.
Nil UUID
A special case where all bits are set to zero (00000000-0000-0000-0000-000000000000). Often used to represent a "null" or unknown value.
A UUID is a 128-bit number usually represented as 32 hexadecimal digits. It is structure depends on the version. For **UUID v4 (Random)**, almost all bits are random, except for version and variant markers. **UUID v1 (Time-based)** is split into a low, mid, and high timestamp, a clock sequence (to handle clock rollback), and a Node ID (MAC address). **UUID v7 (Time-ordered)** starts with a 48-bit timestamp, followed by version, variant, and random bits to ensure uniqueness and database performance.
In UUID v7, the first 48 bits (the first 12 hexadecimal characters) represent the Unix timestamp in milliseconds. For example, if a UUID starts with `018e9533-3333`, the hex value `018e95333333` converts to the decimal `1711933370803`, which corresponds to a specific millisecond in time. Our tool automatically extracts and converts this hex value to a readable date.
UUID v1 is more complex. The timestamp is a 60-bit count of 100-nanosecond intervals since October 15, 1582 (Gregorian epoch). Critically, the timestamp is split and scattered across the UUID string: the 'time-low' is first, followed by 'time-mid', and finally 'time-high'. To decode it, these scattered parts must be reassembled into a single 60-bit number, adjusted to the Unix epoch, and then converted to a date.
Computers process UUIDs as 128-bit binary integers. However, binary is hard for humans to read (it would be 128 zeros and ones!). Hexadecimal (base-16) is a compact way to represent binary data, where every 4 bits maps to one hex digit (0-9, a-f). This compresses the 128 bits into just 32 characters, making it manageable for storage and display while preserving the exact bit pattern.
The **Variant** field determines the internal layout of the UUID bits. It tells the computer how to interpret the rest of the UUID. There are 4 main variants defined by the bits at the start of the variant field: 1. **Variant 1 (RFC 4122/9562)**: The standard for modern UUIDs (v1-v8). Indicated by bits `10xx`. This is what almost everyone uses today. 2. **Variant 0 (NCS backward compatibility)**: Designed for compatibility with the old Apollo Network Computing System (NCS) 1.5. Indicated by bit `0xxx`. 3. **Variant 2 (Microsoft GUID)**: Historically used for Microsoft COM/DCOM GUIDs. Indicated by bits `110x`. 4. **Reserved**: Patterns starting with `111x` are reserved for future definition. Our decoder identifies which variant your UUID belongs to, though most users will only see Variant 1.
For standard UUIDs (Variant 1), the binary bits `10xx` are hardcoded at the start of the variant field. In hexadecimal, `1000` is 8, `1001` is 9, `1010` is A, and `1011` is B. Therefore, the 17th character of any standard UUID will always be one of these four characters.
The variant field indicates the layout of the UUID. Most modern UUIDs (v1, v4, v6, v7) use Variant 1 (RFC 4122/9562), which is indicated by binary `10xx` in the variant bits. This ensures that software knows how to parse the other bits correctly. Other variants exists for backward compatibility with older systems (like NCS or Microsoft GUIDs).