UUID Decoder

What Is a UUID's 128-Bit Structure?

A UUID is a standardized 128-bit number, defined under RFC 4122 (and its successor RFC 9562), used to assign a globally distinct value to records, sessions, and transactions. It's expressed as a 32-character hex string — digits 0–9 and letters a–f — grouped by hyphens into the familiar 8-4-4-4-12 pattern. Each hex digit represents 4 bits, so the full 32 digits encode all 128 bits. The uuid v7 generator produces identifiers that cluster together in B-tree indexes, reducing fragmentation vs. v4.

This example breaks into five fields: time_low, time_mid, time_hi_and_version, clock_seq (which contains the variant), and node — the anatomy of a version 1 UUID specifically, since only time-based versions populate every field with meaning.

Reading the Version and Variant Digits

Two pieces of metadata are present in every valid UUID regardless of how it was generated: the version digit (character 13) and the variant digit (character 17). Parsing the version is direct — if that character is "1" you have a time-based UUID, "4" means randomly generated, and so on. The variant takes more work: it's determined by reading the leading bits of character 17 once converted to binary.

The bits beyond the version and variant fields differ by generation method. A version 1 value encodes a Gregorian-epoch timestamp plus a machine identifier; a version 4 value is entirely random; version 3 and 5 values represent an MD5 or SHA-1 hash of a namespace and name respectively. For load testing or database seeding, the bulk uuid generator generates thousands of unique identifiers in seconds.

How to Check a UUID's Version

Running a UUID version checker against an identifier answers one question: which generation method produced it? Whether you're auditing a database column, debugging a third-party API response, or you just need to check the UUID version before trusting an embedded timestamp, the version digit always sits in the same place. This section covers both a manual eye-check and a scriptable way to verify a UUID's version across many rows at once.

Manual Version Check (By Eye)

To manually identify a UUID version without any tooling, normalize the string first, then count characters:

1. Strip curly braces, quotes, and whitespace, and lowercase the string — the same normalization this UUID version checker applies before decoding.
2. Confirm the string is 36 characters in canonical 8-4-4-4-12 hyphenated form (or 32 characters with no hyphens, sometimes seen as a "simple" or "hex" UUID).
3. Count to the 13th hex digit — the first character of the third group. This is the version field.
4. Match that digit against the version lookup table below to get the UUID version number and generation method.

A UUID version check only tells you the declared version — it doesn't prove the value was generated correctly. A malformed or hand-crafted string can carry a "4" in the version position without its remaining bits being cryptographically random.

Programmatic Version Checks

When you need to check UUID version across thousands of rows instead of one string at a time, a regex or a couple of lines of code does the job faster than pasting each value into a UUID version checker UI:

// JavaScript - extract the version digit
const version = parseInt(uuid.replace(/-/g, '').charAt(12), 16);

// Regex - match specifically a v4 UUID
/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.test(uuid);

# Python - using the standard uuid module
import uuid
u = uuid.UUID(uuid_string)
print(u.version)   # 1-8, or None for a nil UUID

Version field

The 4-bit value at the 13th hex digit that identifies the generation algorithm (1–8).

Canonical form

The 36-character, lowercase, hyphenated 8-4-4-4-12 representation most version-checking code and regexes expect as input.

Version-agnostic parsing

Reading the length and variant of a UUID without assuming a specific version — useful when a field can legally hold any UUID type.

UUID Version Checker: Comparison Table & Common Use Cases

Not every UUID in a codebase was generated the same way, and a UUID version checker is often the fastest way to confirm which method produced a given value before you build logic around it. The table below compares every standard UUID type side by side — useful when auditing a schema that accepts arbitrary identifiers, or when deciding whether an embedded timestamp can actually be trusted.

Version-by-Version Quick Reference

Why Verify a UUID's Version Before Using It

• Privacy exposure — a v1 UUID's node field can contain a real MAC address; checking the version before logging or displaying an ID flags that risk early.
• Index performance — random v4 values fragment B-tree indexes, while sequential v1/v6/v7 values don't; a version check tells you which indexing strategy actually applies to a given column.
• Interoperability — some APIs and schemas only accept a specific version (commonly v4); running a quick version check catches a mismatched identifier before it causes a downstream rejection.
• Deterministic vs. random identity — v3/v5 values are reproducible from the same namespace and name, so two systems independently generating "the same" ID is expected behavior, not a collision.
• Migration audits — confirming which version a legacy dataset actually used (v1 vs. v4 vs. non-standard) before mapping it onto a new schema or database.

Worked Examples

Example 1 — a version 1 UUID: 6ba7b810-9dad-11d1-80b4-00c04fd430c8. The 13th character is "1", confirming version 1. Character 17 is "8" (binary 1000), matching the RFC 4122 variant. The time_low, time_mid, and time_hi fields combine into a Gregorian-epoch timestamp pinpointing creation time, and the node field 00c04fd430c8 reveals the MAC address of the generating machine.

Example 2 — a version 4 UUID: 550e8400-e29b-41d4-a716-446655440000. The 13th character is "4", character 17 is "a" (binary 1010, still the RFC 4122 variant). Decoding confirms there's no recoverable timestamp, node ID, or clock sequence — every bit outside the version/variant positions is purely random, with zero information leakage about the generating host.

Why Decode a UUID?

• Audit trail analysis — interpreting a version 1 or 7 value tells you exactly when a record was created, without a separate timestamp column
• Third-party integration — instantly see whether a value you received is random or time-based, revealing how the remote system assigns its IDs
• Privacy review — identify whether a value could leak information, such as a MAC address exposed through a v1 UUID
• Debugging — confirm a UUID matches the version and format your system expects before trusting it

Frequently Asked Questions