UUID format validator

A successful result returns the normalized lowercase canonical form, the variant encoded by the clock-sequence bits, and the version encoded in the UUID. It accepts uppercase or lowercase hexadecimal letters without silently accepting braces, compact strings, misplaced separators, or non-hexadecimal characters, making it useful for debugging identifiers before they enter an API, database, log pipeline, or validation rule.

What this UUID validator checks

A UUID is 128 bits, but people and systems usually exchange it as 36 visible characters arranged in five groups: eight hexadecimal characters, then four, four, four, and twelve, separated by hyphens. This validator checks that exact representation. It verifies the total length, confirms that every separator appears in the correct position, and rejects any character outside hexadecimal digits and hyphens. Hexadecimal letters can be uppercase or lowercase because their case does not change the underlying bits. Spaces, braces, a URN prefix, compact 32-character values, and trailing punctuation are not silently removed. That strict boundary is valuable when you are testing the contract of an API or database field: an input either matches the documented UUID text form or receives a reason that points to the structural problem. A successful response includes valid as true and provides a lowercase canonical value that can be used for stable comparisons, cache keys, fixtures, and logs. Validation is deterministic and does not query a registry, generate a replacement identifier, or claim that the UUID exists in any external system.

How variant and version are decoded

UUID metadata is encoded inside the identifier rather than looked up. The version is the hexadecimal nibble at the start of the third group, so the validator converts that nibble to an integer from 0 through 15 and reports it directly. Common assigned versions include time-based version 1, name-based versions 3 and 5, random version 4, reordered-time version 6, Unix-time version 7, and custom version 8. The variant comes from the leading bits at the start of the fourth group. A leading zero bit is reported as ncs; the bit pattern 10 is reported as rfc_4122, the family used by modern RFC UUID layouts; 110 is reported as microsoft; and 111 is reported as future. Reporting the bits is different from enforcing one application profile. A structurally correct UUID can carry a reserved version or a legacy variant, so this tool describes what the input encodes instead of pretending every well-formed value must be version 4. Your application can then apply its own policy to the returned fields.

Canonicalization, errors, and practical use

Canonicalization changes only hexadecimal letter case: the five groups and all digits remain untouched, while A through F become lowercase. This means two accepted spellings of the same 128-bit value produce exactly the same canonical string. The validator does not trim whitespace or rewrite an almost-correct value, because automatic cleanup can hide a broken serialization boundary. Instead, an empty value, a non-string value, the wrong character count, misplaced hyphens, and illegal characters produce distinct explanatory messages. That behavior makes the capability suitable for import gates, form diagnostics, test fixtures, and support tools where the cause matters as much as a yes-or-no result. Send one candidate in the text field; the aliases uuid and value are also accepted for integration convenience. The operation costs $0.002 per item through the API and runs with no network access, randomness, clock, model, or persistent storage. It checks syntax and embedded metadata only. It cannot determine uniqueness, ownership, database presence, generation quality, or whether a syntactically valid identifier is appropriate for a particular protocol.