UUID Decoder
Decode any UUID to see its version, variant, and embedded timestamp. Supports versions 1 through 7.
UUID
UUID Versions
Timestamp (100-ns intervals since 1582-10-15) and node (MAC address). Sortable by time but leaks the host MAC.
Deterministic hash of a namespace UUID + name using MD5. Same input always produces the same UUID.
122 bits of cryptographic randomness. The most commonly used version today. No embedded timestamp or node.
Same concept as v3 but uses SHA-1 instead of MD5. Preferred over v3 for new systems.
Same timestamp as v1 but with the bits reordered for natural lexicographic sorting. Also includes clock sequence and node.
48-bit Unix timestamp in milliseconds plus random bits. Sortable, no MAC leak, and the recommended choice for new systems.
The UUID decoder takes any UUID and unpacks its version, variant, and (where applicable) the embedded creation timestamp. Different UUID versions encode different information: v1 and v6 contain a Gregorian timestamp plus the generating machine's MAC address; v7 contains a Unix millisecond timestamp; v3, v4, and v5 do not embed time at all. The decoder applies the right interpretation based on the version nibble, so you can drop any UUID in and read what it actually represents.
What Each UUID Version Contains
A UUID is a 128-bit value displayed as 32 hex characters in the dashed 8-4-4-4-12 layout. Two hex digits (the 13th character and the first nibble of the 17th character) encode the version and variant. Everything else is version-specific:
- v1 (Date-Time + MAC): 60-bit timestamp counted in 100-nanosecond intervals since October 15, 1582 (the start of the Gregorian calendar), plus a 14-bit clock sequence and a 48-bit node identifier (originally the MAC address of the generating machine). Embeds when and where the UUID was made.
- v3 (Name-Based MD5): a deterministic hash of a namespace UUID and a name string using MD5. The same input always produces the same UUID. No timestamp.
- v4 (Random): 122 bits of randomness with no embedded information. The default for most applications because it requires no inputs and is collision-free in practice.
- v5 (Name-Based SHA-1): like v3 but using SHA-1 instead of MD5. Preferred over v3 for new applications. No timestamp.
- v6 (Reordered Time, RFC 9562): the same data as v1 (Gregorian timestamp, clock sequence, node) but with the bits reordered so the timestamp is in the high-order position, making the value naturally sortable.
- v7 (Unix Epoch Time, RFC 9562): 48-bit Unix millisecond timestamp followed by 74 bits of randomness. Sortable by creation time and the recommended choice for new systems that need a time-ordered UUID.
- v8 (Custom): reserved for application-specific layouts. Anyone can define their own meaning for the bits as long as they fill the version field with 8 and follow the variant rules.
How the Decoder Works
Paste a UUID in any format - canonical with dashes, no dashes, in braces, or as a URN. The decoder normalizes the input, reads the version nibble (the first hex digit of the third group), and applies the matching extraction rules. The result includes:
- Version and variant: the numeric version (1-8) plus the human-readable name, and the variant string (RFC 4122 / RFC 9562 for almost all modern UUIDs).
- Timestamp section (v1, v6, v7 only): the embedded date in Unix seconds, full readable form, ISO 8601, and a relative description.
- Clock sequence and MAC (v1, v6 only): the 14-bit sequence used to avoid collisions when the clock is reset, and the 48-bit node ID, which on many systems was the generating machine's MAC address.
- Format variants: the same UUID rendered as canonical, with braces, as a URN, as a hex string without dashes, and as a 128-bit integer for cross-format storage and search.
For other identifiers that also embed creation timestamps, see the ULID decoder, the Snowflake decoder (Discord, Twitter, Instagram), or the MongoDB ObjectId decoder. To create new UUIDs of any version, the UUID generator handles v4, v7, and ULID.
When to Decode a UUID
Most UUIDs in logs and APIs are v4 (purely random), but enough of them are not that being able to inspect any UUID is a useful debugging skill. Common scenarios:
- Tracing creation order: if a UUID is v1, v6, or v7, the embedded timestamp tells you when the record was created without a database lookup.
- Privacy auditing: v1 UUIDs leak the generating machine's MAC address. If a service exposes v1 UUIDs in public APIs, it may be inadvertently disclosing infrastructure details. The decoder reveals the node field so you can spot this.
- Cross-system migrations: when moving data between systems, knowing whether the source uses v1, v4, v7, or a custom v8 format affects how you store and query the values downstream.
- Detecting test fixtures: UUIDs in test code are often hand-crafted (00000000-0000-0000-0000-000000000001) or fully zeroed. The decoder spots these as having invalid version/variant nibbles.
- Identifying tooling: different UUID generators have signature quirks. Java's default produces v4 with a specific random pattern; some Python libraries produce v1; AWS's Aurora cluster IDs are v4 with a fixed prefix. The decoder reveals these patterns at a glance.
UUID v1 and the MAC Address Concern
UUID v1 was the original UUID format and was designed to use the generating machine's MAC address as the 48-bit node identifier. This guaranteed uniqueness without coordination but also leaked the machine's hardware address. Modern implementations of v1 use a random number with the multicast bit set instead of a real MAC address, but legacy systems and some embedded platforms still emit real MACs.
If the decoded node value matches a real MAC address pattern (the second-least-significant bit of the first byte is 0, indicating a unicast address), the v1 UUID was likely generated on a real machine and the value is the MAC of that machine. If the bit is 1, the node is a random value following the modern v1 specification. v6 was designed as a drop-in replacement for v1 that keeps the timestamp ordering but encourages random nodes by default.
Frequently Asked Questions
The version is encoded in the 13th hex character of the UUID (the first character of the third dash-separated group). For 550e8400-e29b-41d4-a716-446655440000, the 13th hex character is the 4 in 41d4, so this is a v4 UUID. The decoder reads this nibble automatically and reports the version with its full name (Random, Date-Time + MAC, Unix Epoch Time, and so on).
v1, v6, and v7. UUID v1 and v6 use a 60-bit Gregorian timestamp counted in 100-nanosecond intervals from October 15, 1582 (only the bit layout differs between them). UUID v7 uses a 48-bit Unix timestamp in milliseconds. UUID v3, v4, v5, and v8 do not have an embedded timestamp; v3 and v5 are hashes, v4 is random, and v8 is custom.
The variant identifies which UUID specification the value follows. Almost every modern UUID is variant RFC 4122 (or its successor RFC 9562), which is what the dashed 8-4-4-4-12 hex layout implies. Older formats (NCS reserved, Microsoft COM/DCOM) exist for backward compatibility but are rare. If the decoder reports a variant other than RFC 4122/9562, the UUID likely came from a legacy system or a corrupted source.
Sometimes. The v1 specification calls for the generating machine's MAC address in the node field, which leaks hardware information. Modern v1 implementations usually substitute a random number with the multicast bit set to avoid this. The decoder shows the node field as a hex value; if it looks like a real MAC pattern (with the unicast bit set), the UUID may reveal the original machine's address.
Both contain the same Gregorian timestamp, clock sequence, and node fields. v1 stores the timestamp with the lowest-order bits first (which makes consecutive UUIDs appear unordered), while v6 reorders the bits so the timestamp is in high-order position (which makes them sort by creation time as strings). v6 is the recommended modern replacement for v1 in any application that benefits from time-ordered IDs.
For a database primary key, v7 or ULID is usually a better choice than v4 because both sort by creation time, which improves index locality and pagination performance. For a session token or a CSRF token, v4 is fine because random is what matters. v7 stays in the standard UUID format and is supported in RFC 9562; ULID has a more compact 26-character representation. Both encode the same kind of timestamp.
No. UUID v4 contains 122 bits of randomness with no embedded timestamp. The decoder will not show a timestamp section because there is nothing to read. If you need creation-time information for an existing record, store it in a separate field or migrate to v7/v6 for new records. The decoder still shows the version, variant, and format variants for v4 so you can confirm what you have.
Canonical form with dashes (550e8400-e29b-41d4-a716-446655440000), without dashes (550e8400e29b41d4a716446655440000), wrapped in braces ({550e8400-e29b-41d4-a716-446655440000}), and as a URN (urn:uuid:550e8400-e29b-41d4-a716-446655440000). The decoder normalizes the input to canonical form before parsing, so any of those forms produces the same result.
The nil UUID is 00000000-0000-0000-0000-000000000000, the all-zeros value. It is reserved by the UUID specification as a placeholder meaning no value or absence, similar to NULL in SQL. The decoder will show version 0 and variant NCS reserved, neither of which matches a real UUID format. Treat any nil UUID seen in production as a missing or default value rather than a valid identifier.
Practically yes, mathematically no. UUID v4 has 122 bits of randomness, giving 2^122 (about 5 followed by 36 zeros) possible values. A collision is so unlikely that you can treat UUIDs as unique without coordination. Time-based versions (v1, v6, v7) use additional fields (node, clock sequence, randomness) to prevent collisions even when generated by the same machine in the same nanosecond. For all real-world purposes, a UUID can be used as a primary key without uniqueness checks.