UUID Versions, Variants, and Validation Explained

Validate UUID text before interpreting its bits

The familiar UUID string is a textual representation of 128 bits. In canonical form it contains five hexadecimal groups with lengths 8-4-4-4-12. A missing hyphen, brace wrapper, URN prefix, quote, comma, or internal space is a text-format issue that should be resolved before version and variant fields are interpreted.

VetaTool follows that order. It first checks canonical UUID text, then reads the encoded version and RFC-compatible variant. Keeping those checks separate makes an error easier to diagnose because a format failure is not confused with a valid-looking UUID whose version or variant bits are unsupported.

550e8400-e29b-41d4-a716-446655440000

550e8400e29b41d4a716446655440000

Read the version nibble from the third group

RFC 9562 defines the version field in four bits of the UUID. In canonical text, that field is visible as the first hexadecimal digit of the third group. A 4 in that position identifies UUIDv4; a 7 identifies UUIDv7. VetaTool currently recognizes versions 1 through 8 after the canonical format check succeeds.

The version number identifies a layout, not a quality score. Two UUIDs can both be structurally valid while using very different generation rules, and an application may intentionally permit only a subset of versions.

• v1: Gregorian-time-based layout with clock sequence and node fields.
• v2: reserved for DCE Security; RFC 9562 does not redefine the detailed DCE Security semantics.
• v3: namespace-and-name UUID derived with MD5.
• v4: random or pseudorandom UUID with required version and variant bits.
• v5: namespace-and-name UUID derived with SHA-1.
• v6: reordered Gregorian-time layout intended to improve database locality compared with v1.
• v7: Unix Epoch milliseconds followed by additional data for uniqueness and optional monotonicity.
• v8: application- or vendor-defined layout with only the version and variant fields fixed by the RFC.

Check the variant separately from the version

The variant determines how the rest of the UUID bits are interpreted. For the UUID layout defined by RFC 9562, the two most significant bits of octet 8 are 10. In canonical UUID text, the first hexadecimal digit of the fourth group therefore falls in the range 8 through B.

That field is independent of the version nibble. A UUID can contain a valid version 4 nibble but still fail because the fourth group starts with a digit outside the accepted RFC variant range.

550e8400-e29b-41d4-a716-446655440000

550e8400-e29b-41d4-7716-446655440000

Know what structural validation does not prove

A UUID inspector can read fixed fields from the final 128-bit value, but many important properties depend on how that value was produced. A UUIDv4 label does not prove that the random bits came from a cryptographically secure generator. A UUIDv7 label does not prove that its timestamp matches the real creation time or that a generator maintained monotonic order.

Name-based UUIDs have the same boundary. Detecting v3 or v5 does not reveal or verify the namespace and name that were hashed. UUIDv8 is even more application-specific because the RFC deliberately leaves 122 bits available for custom use after the required version and variant fields are set.

• Check generator provenance when secure randomness matters.
• Use a version-aware decoder when timestamp extraction or ordering matters.
• Recompute name-based UUIDs from the expected namespace and name when those inputs are part of the contract.
• Apply database uniqueness constraints and protocol-specific version allowlists separately from UUID text validation.

Choose a UUID version for the property you need

For browser-generated opaque identifiers, UUIDv4 remains a straightforward choice when secure random generation is available. The Web Crypto randomUUID API produces UUIDv4 values with a cryptographically secure random number generator, which is why the VetaTool generator uses browser Crypto rather than Math.random.

UUIDv7 is useful when systems want an identifier whose leading bits carry Unix-time information and therefore have better time ordering characteristics. Name-based v3 and v5 are deterministic for the same namespace and name, while v8 is reserved for designs that intentionally need a custom UUID-compatible layout.

Use a repeatable UUID validation workflow

Start with the text representation and only move to semantic checks after the UUID is structurally parseable. This prevents application rules from hiding a simple copy-and-paste problem and prevents a structural pass from being mistaken for full provenance verification.

• Normalize only the whitespace behavior your application explicitly allows; keep wrappers and punctuation visible while diagnosing format failures.
• Confirm the canonical 8-4-4-4-12 hexadecimal layout.
• Read the version nibble and decide whether that version is allowed by the receiving system.
• Check the RFC variant independently from the version.
• Validate generation-specific properties such as randomness, timestamps, namespaces, or custom v8 fields with a version-aware source of truth.
• Enforce uniqueness and authorization at the application or database layer rather than treating UUID syntax as a security guarantee.