UUID Version Detector

A UUID (Universally Unique Identifier) version specifies the mathematical algorithm, timestamp encoding, or entropy source used to generate a 128-bit identifier. Standardized originally by the Internet Engineering Task Force (IETF) in RFC 4122 and substantially updated in RFC 9562, UUID versions ensure that systems across the globe can interpret identifiers consistently without central coordination. While every standard UUID is physically 128 bits (16 bytes) in length and represented as a 32-character hexadecimal string with 4 hyphens (8-4-4-4-12), the internal arrangement of those 128 bits differs fundamentally depending on the version. Knowing the version tells you whether an ID contains a physical hardware MAC address, a millisecond timestamp, a cryptographic namespace digest, or pure pseudorandom entropy.

How UUID Versions Work Under the Hood

UUID versions operate by allocating specific bit ranges within the 128-bit binary payload to convey metadata alongside identification data. Regardless of the version, exactly four bits (bits 48 through 51 in big-endian order) are permanently reserved to store the version number, encoded as an unsigned integer from 1 to 8. Concurrently, between two and three bits (bits 64 through 66) are dedicated to the variant field, defining the structural layout and endianness of the entire record. Because these metadata bits are fixed in location, software parsers can read the exact version and variant of any UUID without prior knowledge of the generating application, database engine, or programming language.

Where Is the Version Stored Inside a UUID?

In the canonical human-readable string representation of a UUID (formatted as xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx), the version is stored at character position 13 (the M character), which corresponds to the first character of the third hyphen-separated group. In binary terms, this occupies bits 48 to 51 (the highest 4 bits of octet 6, named time_hi_and_version in the specification). For instance, in the UUID 550e8400-e29b-41d4-a716-446655440000, the third group begins with 4, indicating Version 4. Immediately following the third hyphen, character position 17 (the N character) encodes the variant in its highest bits. When N is 8, 9, a, or b (binary 1000 through 1011), the UUID conforms to the standard IETF RFC 4122 / RFC 9562 specification.

Comprehensive Comparison: UUID Versions 1 Through 8

RFC 4122 and RFC 9562 define eight distinct UUID versions tailored for different computational paradigms: Version 1 combines a 60-bit Gregorian timestamp with the generating computer’s 48-bit MAC address; Version 2 (DCE Security) embeds POSIX local user and group identifiers for domain-level security tokens; Version 3 produces deterministic identifiers using MD5 hashing over a namespace UUID and input name; Version 4 uses 122 bits of cryptographically secure random entropy (CSPRNG) for general-purpose uniqueness; Version 5 produces deterministic IDs like v3 but uses the collision-resistant SHA-1 algorithm; Version 6 reorders the Gregorian timestamp bits of v1 so the most significant bits come first, allowing lexicographical sorting in database B-Trees; Version 7 encodes a 48-bit Unix Epoch millisecond timestamp followed by random sub-millisecond sequence counter and entropy bits, serving as the modern industry standard for database primary keys; and Version 8 provides a standardized container for vendor-specific, experimental, or customized 128-bit formats.

UUID Version vs. UUID Variant: The Critical Difference

Developers frequently confuse UUID versions and UUID variants, but they serve two distinct architectural roles. The variant determines the overarching binary layout, bit interpretation, and historical lineage of the 128-bit identifier. There are four defined variants: Variant 0 (NCS backward compatibility, high bit 0), Variant 1 (RFC 4122 / RFC 9562 IETF standard, high bits 10), Variant 2 (Microsoft COM GUID backward compatibility, high bits 110), and Variant 3 (Reserved for future definition, high bits 111). Within Variant 1 (which encompasses virtually all modern software identifiers), the version number (1 through 8) specifies the precise internal algorithm used to generate the remaining payload bits. In short, the variant defines the grammar of the UUID, while the version defines its internal vocabulary.

Why Knowing Your UUID Version Matters in Production

Identifying the UUID version is crucial for application performance, data security, and compliance. First, using UUID v1 in modern web services creates a severe privacy and security hazard because it permanently exposes the network MAC address of the host machine and reveals exact creation timestamps to external attackers. Second, database indexing performance varies drastically: inserting completely random UUID v4 values into clustered B-Tree indexes (such as PostgreSQL primary keys or MySQL InnoDB tables) causes continuous index page splits, disk fragmentation, and write degradation. In contrast, replacing v4 with time-ordered UUID v7 or v6 delivers sequential insertion performance comparable to auto-incrementing integers while preserving distributed uniqueness. Detecting your UUID versions lets you audit legacy data, verify encryption standards, and plan migrations safely.

How to Manually Identify a UUID Version (The 13th Hex Rule)

You can instantly inspect the version of any standard canonical UUID by applying "The 13th Hex Rule" without writing a single line of code. Write or locate your 36-character UUID string in standard 8-4-4-4-12 hyphenated format. Skip the first two groups (the first 8 characters and 4 characters, totaling 12 hex digits). Look directly at the very first character of the third group. That single hexadecimal character represents the exact UUID version: a digit of 1 signifies UUID v1, 4 indicates UUID v4, 7 indicates UUID v7, and so forth. Next, glance at the first character of the fourth group: if it is 8, 9, a, or b (or uppercase A, B), the identifier is guaranteed to be a compliant RFC 4122/9562 standard UUID. Our online tool automates this inspection instantly, analyzing all 128 bits to verify version nibbles, variant bitmasks, and structural validity simultaneously.

Practical Developer Use Cases & Architectural Best Practices

In modern software engineering, different UUID versions excel in specific architectural scenarios. UUID v4 is the default choice for ephemeral tokens, session identifiers, password reset secrets, OAuth state parameters, and distributed trace IDs where predictable ordering is unnecessary or undesirable. UUID v7 is the undisputed best practice for relational database primary keys, distributed event stores, and message queues where entities require millisecond-level time sorting, index locality, and zero database round-trips. UUID v5 is optimal for deterministic mapping, such as generating reproducible resource identifiers across federated microservices from domain names or URLs. Finally, Nil UUIDs (00000000-0000-0000-0000-000000000000) serve as uninitialized null objects in typed schemas, while Max UUIDs (ffffffff-ffff-ffff-ffff-ffffffffffff) act as ceiling bounds in range queries.

Frequently Asked Questions About UUID Versions