Trexmi
Validator Ready

UUID Validator

Validate canonical UUID syntax, identify versions 1–8, recognize Nil and Max UUIDs, report the variant, and explain format failures.

Canonical 8-4-4-4-12 format check Versions 1 through 8 Nil and Max UUID recognition Variant classification
Validation checks canonical UUID syntax, version and RFC variant bits.
INPUT UUID to validate *
0 chars0 words0 lines
Paste the source value for this specific transformation. Example: 550e8400-e29b-41d4-a716-446655440000
Ctrl / ⌘ + Enter
UUID validation result
About the tool

What UUID Validator does

UUID Validator checks the canonical 8-4-4-4-12 textual form, reports the version nibble for versions 1 through 8, classifies the encoded variant, and recognizes the all-zero Nil UUID and all-one Max UUID.

A valid result describes identifier structure only. It cannot prove uniqueness, authenticity, ownership, authorization, or the existence of a matching database record. Input is normalized to lowercase for the report without contacting another service.

UUID Validator showing canonical groups version and variant
Check UUID layout, version, variant, and any specific format error.

How to use

  1. Copy the complete value. Preserve all four hyphens.
  2. Run the validator. Uppercase hexadecimal letters are normalized to lowercase.
  3. Read the result. Review validity, version, variant, format, and special-value status.
  4. Correct syntax if needed. Use the stated reason for length, character, hyphen, or version errors.
  5. Confirm application meaning. Query the issuing system separately when existence or permission matters.
Built for the task

Why use UUID Validator?

Focused controls, predictable output, and a workflow designed around this exact transformation.

01

Canonical format check

Require exactly 36 visible characters in the 8-4-4-4-12 hyphenated representation.

02

Version detection

Read the version nibble and accept versions 1 through 8 as supported layouts.

03

Variant classification

Report NCS, RFC, Microsoft legacy, or reserved variant bits without hiding the distinction.

04

No identity claim

The guide separates structural validation from uniqueness, ownership, and database existence.

Useful answers

Questions about UUID Validator

Practical details about input, output, privacy, limits, and the best way to use this tool.

01 What UUID format is accepted?

The validator expects 32 hexadecimal characters in the canonical 8-4-4-4-12 layout with four hyphens.

02 Are uppercase UUIDs valid?

Yes. Uppercase hexadecimal letters are accepted and normalized to lowercase in the result.

03 Which UUID versions are recognized?

The version nibble is accepted when it is 1 through 8. Nil and Max are handled as special UUID values.

04 What does the variant field mean?

It classifies the layout bits as NCS legacy, RFC 4122 / RFC 9562, Microsoft legacy, or reserved.

05 Does valid mean the UUID exists?

No. A fabricated or duplicated UUID can be structurally valid. Check existence in the issuing application.

06 Does a UUID prove authorization?

No. Never treat knowledge of an identifier as permission to access the represented resource.

07 Why is a compact UUID rejected?

The current validator intentionally requires canonical hyphen placement rather than the 32-character compact representation.

08 Can hidden characters cause failure?

Leading and trailing whitespace is trimmed, but embedded whitespace or non-hexadecimal characters make the value invalid.

Continue this workflow

Related tools for UUID Validator

Open the next relevant utility without returning to the main directory.

Related toolMCP Schema Validator Related toolXML Validator Related toolCSV Validator Related toolBCrypt Verify Related toolJSON Validator Related toolYAML Validator Related toolJSON Schema Validator Related toolPassword Strength Checker

Examples

Random UUID v4

The canonical group layout and version nibble are recognized.

Input 
550e8400-e29b-41d4-a716-446655440000
Output 
Valid · version 4 · RFC 4122 / RFC 9562 variant

Nil UUID

RFC 9562 defines this all-zero special value separately from numbered versions.

Input 
00000000-0000-0000-0000-000000000000
Output 
Valid Nil UUID

Missing hyphens

This validator requires the 36-character hyphenated representation.

Input 
550e8400e29b41d4a716446655440000
Output 
Invalid canonical format

Canonical UUID format

The accepted representation contains 32 hexadecimal digits separated into groups of 8, 4, 4, 4, and 12 characters. With four hyphens it has 36 visible characters. The check is intentionally strict: braces, URN prefixes, compact text, and extra punctuation are not silently removed.

Letter case does not change the hexadecimal value. The result normalizes accepted input to lowercase so identifiers copied from different systems are easier to compare.

How the version is identified

The first hexadecimal character in the third group is the version nibble. The processor reports versions 1 through 8. These versions describe different generation layouts, including time-based, name-based, random, reordered-time, Unix-time, and application-defined forms.

Validation does not recompute namespace hashes, randomness quality, timestamps, or application-defined version 8 data. It checks the visible structure and encoded version field.

What the variant report tells you

The leading bits in the fourth group distinguish layout families. The result labels NCS legacy, RFC 4122 / RFC 9562, Microsoft legacy, or reserved values. This classification is reported independently from the supported version nibble so migrations can expose unexpected legacy layouts rather than hiding them.

Applications may enforce a narrower rule, such as requiring both RFC variant bits and version 4. Apply that business rule in the receiving system after structural validation.

Nil and Max UUID values

The Nil UUID contains all zero bits, while the Max UUID contains all one bits. They are valid special values defined by RFC 9562 and do not carry a numbered version in this report. Applications often use them as sentinels, so confirm whether the destination permits them.

What UUID validation cannot prove

  • The identifier is unique in a real dataset.
  • The referenced record exists.
  • The UUID was generated with secure randomness.
  • A timestamp field reflects a truthful creation time.
  • The user is authorized to access the resource.

Review RFC 9562 for UUID layouts, versions, variants, and special values.

Related Trexmi tools

Create v4 or v7 identifiers with UUID Generator, inspect version-specific fields with UUID Decoder, or validate an API payload with JSON Validator.