UUID / ULID Decoder

UUID Decoder reads the hidden structure inside a UUID or a ULID. Paste an identifier and the tool validates its format, reports its version and variant, and extracts whatever metadata the layout carries: creation timestamps, the node field, and the clock sequence. Developers use it to confirm which version a library really generates, to date a record from its primary key, and to check identifiers before a migration. All parsing happens in the browser.

Reading the Five Groups

A UUID is a 128-bit value written as 32 hexadecimal digits split 8-4-4-4-12 with hyphens. Each group has a conventional role, and the decoder labels them: the first group is time_low, the second is time_mid, the third combines the 4-bit version with the high time bits, the fourth combines the variant with the clock sequence, and the fifth is the node. Two positions decide most of the meaning. The thirteenth hexadecimal digit — the first character of the third group — is the version nibble, so a 4 there means random and a 1 means time-based. The nineteenth digit, the first of the fourth group, holds the variant bits, which tell a parser whether the value follows RFC 4122, an older NCS layout, or the Microsoft GUID convention.

Versions at a Glance

Version	Basis	Timestamp decoded here
v1	Time since 1582 plus node	Yes
v2	DCE security	No
v3	MD5 name-based	No
v4	Random	No
v5	SHA-1 name-based	No
v6	Reordered time	No (not parsed)
v7	Unix milliseconds plus random	Yes
v8	Custom, vendor-defined	No

The practical takeaway: if you need to know when an identifier was created, only v1 and v7 will answer. A v4 value is opaque by design, and v3 and v5 are deterministic hashes of a namespace and name, so they reveal nothing about time.

Worked Examples: v4, v1, and v7

For the common random identifier 550e8400-e29b-41d4-a716-446655440000, the decoder reports version 4, variant RFC 4122/DCE, node 44:66:55:44:00:00, clock sequence 0x2716, and the random badge. No timestamp row appears, because v4 has none.

For the version 1 identifier 04afc000-833b-11ee-a716-446655440000, it reports version 1 and an embedded timestamp of 2023-11-14T22:13:20.000Z. The node is 44:66:55:44:00:00 and the clock sequence is 0x2716. The node is real generator information here, which is the privacy concern discussed below.

For the version 7 identifier 018bcfe5-6800-7abc-8def-0123456789ab, it reports version 7 and the same 2023-11-14T22:13:20.000Z timestamp, read from the leading 48-bit millisecond value. The node row still renders because the layout always includes those bytes, but for v7 they are random rather than a hardware address.

Timestamps in ULIDs and Sortable Keys

A ULID is also 128 bits, written as 26 characters of Crockford Base32, an alphabet that omits the easily confused letters I, L, O, and U. The first 10 characters encode a 48-bit Unix millisecond timestamp and the remaining 16 are randomness. Pasting 01HF7YAT007ZZZZZZZZZZZZZZZ yields a timestamp of 2023-11-14T22:13:20.000Z, a timestamp part of 01HF7YAT00, and a random part of 7ZZZZZZZZZZZZZZZ. Because the time is at the front and the encoding is lexicographic, ULIDs sort by creation time exactly like v7 UUIDs, but in a shorter, URL-safe string.

Database engine choice often decides the version more than any specification does. Random v4 keys scatter inserts across a B-tree, which keeps writes balanced but forces index pages to split in random order and can bloat storage over time. Time-ordered v7 and ULID keys append near the end of the index, so inserts stay on the hot page and range queries by creation time stay cheap, at the cost of a slightly guessable creation window. A ULID stores as a 26-character string that sorts the same way in any language, while v7 keeps the familiar UUID shape and fits existing uuid columns. If a table already keys on 36-character UUIDs, v7 is the lower-friction upgrade; if you control the schema and want compact, case-insensitive keys, a ULID is often the better fit.

Where the Decoder Stops

This is a reader, not a generator or a validator for cryptographic purposes. It does not reconstruct the namespace and name behind a v3 or v5 UUID, decode the DCE domain of a v2, or interpret a v8 vendor layout. Version 6 is time-based but the tool does not unpack it. A v1 value with a timestamp before the Unix epoch returns no date, and the strict format check rejects braces, missing hyphens, and urn prefixes. It also cannot tell you whether a given identifier is authentic or unique — only whether its structure is internally consistent.

Privacy Notes for v1

The node field in a version 1 UUID is historically the generating machine’s MAC address, and the clock sequence plus the 60-bit timestamp narrow down both the device and the moment. A v1 key exposed in a public API, a shared spreadsheet, or a support ticket can therefore leak more than intended. Modern libraries often replace the node with random bytes, but you cannot tell from the value alone. When reviewing identifiers, treat a v1 node as sensitive; prefer v4 when uniqueness only matters, and prefer v7 when you want sortable keys while accepting that the creation time is visible.

Related Tools

• UUID Generator
• Timestamp Converter
• JWT Decoder
• Hash Generator