Not all UUIDs are created equal, even though they're all formatted as the same 36-character, hyphen-separated hex string. The version nibble (the first hex digit of the third group) tells you how the UUID was actually generated, and that generation method has real consequences for privacy, sortability, and collision resistance that the string alone doesn't advertise.
Version 1 UUIDs embed the generating machine's MAC address and a timestamp with 100-nanosecond precision, which made them useful for debugging and ordering but is a genuine privacy problem — a v1 UUID in a public API response or database export leaks the hardware identity of whatever machine created it, permanently, since MAC addresses don't rotate. Version 4 is the common case: 122 bits of randomness with no embedded metadata, which is exactly why v4 UUIDs are the safe default when you don't need sortability. Version 7, standardized more recently, deliberately reintroduces a timestamp prefix (millisecond Unix time) specifically so UUIDs sort chronologically like an auto-incrementing ID, while keeping the remaining bits random — a considered privacy/utility tradeoff rather than an accident.
ULIDs solve the same sortability problem as v7 but predate the UUIDv7 standard and use a different, non-hyphenated encoding (Crockford base32, 26 characters) with a 48-bit millisecond timestamp followed by 80 bits of randomness. They're not technically UUIDs at all, but they occupy the same niche and are common enough to be worth detecting on sight.
This decoder identifies the version and variant bits, and — for v1, v7, and ULID — extracts and displays the embedded timestamp; for v1 specifically, it also extracts and displays the embedded MAC address as an explicit privacy warning rather than a neutral fact.
Edge cases worth knowing
- A v1 UUID with an all-zero or clearly synthetic MAC
- Some v1 generators use a randomly-generated 'multicast' MAC (with the low bit of the first byte set) instead of the real hardware address, specifically to avoid this privacy leak. This decoder checks that multicast bit and notes when the embedded MAC is synthetic rather than a real NIC address.
- A v4 UUID with suspiciously repetitive hex digits
- A truly random v4 UUID should look like noise. A string like 44444444-4444-4444-8444-444444444444 is version-and-variant-correct but has almost no entropy in its random bits — a sign of a broken or mocked random source rather than a real UUID generator, flagged as an info-level entropy warning.
- A ULID versus a v7 UUID for the same use case
- Both encode a millisecond timestamp plus randomness and both sort lexicographically by creation time, but they aren't interchangeable on the wire — a ULID is base32 with no hyphens, a UUIDv7 is hex with hyphens in the standard UUID layout. This decoder identifies each by its actual shape rather than assuming one or the other.
Common mistakes
- Using v1 UUIDs in any externally-visible identifier and not realizing the generating machine's MAC address is permanently embedded in it.
- Assuming all UUIDs are equally random — v1, v7, and ULID are all partially predictable because of their timestamp prefix.
- Mixing v4 (random) and v7/ULID (sortable) in the same table's primary key column, losing the sort benefit for the mixed set.
- Treating a ULID as just 'a different-looking UUID' instead of recognizing it needs its own parser (26-character base32, not 36-character hex).