How UUID Variant Detection Works (RFC 4122)
Every valid UUID contains a variant field that determines the layout of the remaining bits. This field is stored in the most significant bits of the third group and must follow strict rules defined in RFC 4122. Most online validators ignore this crucial detail, leading to false positives.
The Four Defined Variants
There are four possible UUID variants, but only one is considered standard today:
- Variant 0 (0xxx) – NCS backward compatibility (obsolete)
- Variant 1 (10xx) – RFC 4122 standard (the one we use)
- Variant 2 (110x) – Microsoft GUID format
- Variant 3 (111x) – Reserved for future definition
Only variant 1 is RFC-compliant for new implementations. In hexadecimal, this means the third group must start with 8, 9, a, or b. Anything else is invalid.
Why It Matters
Many UUID generators, especially older ones or non-compliant libraries, produce UUIDs with incorrect variants (often starting with c, d, e, f). These appear to work locally but cause issues in strict systems like PostgreSQL, Java UUID class, or distributed databases.
How This Tool Checks It
The validator uses a precise bit masking on the variant field. As soon as a UUID fails the 89ab rule, it is immediately marked invalid, even if the rest of the format looks correct. This eliminates false positives that plague simpler regex-only checkers.
This strict approach guarantees that any UUID marked Valid by this tool will work correctly in every RFC-compliant system worldwide.
Never trust a validator that accepts UUIDs starting with c, d, e, or f in the third group.