Canonical UUID text has 36 characters in an 8-4-4-4-12 pattern. Removing four hyphens leaves 32 hexadecimal digits, or 16 bytes. That surface pattern is only the first layer: ordinary UUIDs also carry a version nibble and a variant field with defined bit positions.
Canonical means one exact representation
RFC 9562 presents the common hexadecimal form with lowercase examples and fixed hyphens. Other contexts accept uppercase, braces, a compact string or a urn:uuid prefix, but those are separate presentation contracts. A strict field validator should not silently trim, unwrap or change case, because automatic repair can hide a mismatch between producer and consumer. UUIDLens therefore validates only lowercase 8-4-4-4-12 input.
Version and variant are separate fields
The first hexadecimal digit of the third group is the version. For example, 4 marks UUIDv4 and 7 marks UUIDv7. The leading bits of the fourth group encode the variant; canonical RFC UUIDs produce a first digit of 8, 9, a or b there. Reading only the version is incomplete. Nil and Max are special UUIDs and are classified before ordinary version and variant rules.
Validation proves structure, not provenance
A string can have perfect syntax, version and variant fields while referring to no record at all. It can also be copied, guessed, logged or supplied by an untrusted party. Structural validation should happen before parsing or storage, but authorization and existence checks belong to the receiving application. UUIDLens has no database and intentionally reports no ownership, authenticity, uniqueness or access decision.