GUID Validator: Check Format, Version and Variant

How to use the guid validator

1. Paste or type your GUID or UUID string into the input field.
2. The guid validator checks the format automatically as you type.
3. Review the result rows for validity, normalized form, version, and variant.
4. Copy the normalized value for use in your code or database.

How GUID validation works

A GUID (Globally Unique Identifier) is a 128-bit value typically written as 32 hexadecimal characters split into five groups by hyphens: 8-4-4-4-12. The guid validator strips common wrappers like curly braces or the urn:uuid: prefix, then checks that what is left is either 32 bare hex digits or the 8-4-4-4-12 hyphenated grouping.

Once the raw hex is confirmed, the tool reads specific bit positions to determine the version and variant. For example, in 550e8400-e29b-41d4-a716-446655440000, the character after the third hyphen is 4, indicating version 4. The first character of the fourth group is a (binary 1010), which places it in the RFC 4122 variant because the top two bits are 10.

GUID versions explained

The version number occupies four bits in the 13th octet of the identifier. Each version defines how the value was generated:

If you need to create new identifiers rather than check existing ones, use a guid generator to produce version 4 values on demand.

Understanding variants

The variant field determines the layout of the GUID. It is encoded in the most significant bits of the clock_seq_hi_and_reserved octet (the first character of the fourth group).

• RFC 4122 (variant 1): Top two bits are 10. Hex characters 8, 9, a, b. This covers virtually all modern UUIDs.
• NCS backward compatibility: Top bit is 0. Hex characters 0 through 7.
• Microsoft COM/DCOM: Top three bits are 110. Hex characters c, d.
• Reserved for future use: Top three bits are 111. Hex characters e, f.

This guid validator reports the detected variant so you can confirm the identifier conforms to the standard your system expects. The version digit only has a meaning for the RFC 4122 variant (8, 9, a or b), so for the other variants the tool shows the version as not defined instead of guessing. Versions 6 to 8 come from RFC 9562, which replaced RFC 4122.

Accepted input formats

The tool normalizes several common representations before validating. All of these resolve to the same 32-hex-digit core:

• Standard hyphenated: 550e8400-e29b-41d4-a716-446655440000
• No hyphens: 550e8400e29b41d4a716446655440000
• Curly braces: {550e8400-e29b-41d4-a716-446655440000}
• URN prefix: urn:uuid:550e8400-e29b-41d4-a716-446655440000
• Mixed case: 550E8400-E29B-41D4-A716-446655440000

The normalized output always uses lowercase hyphenated form, which is the canonical representation defined in RFC 4122. If you also need to validate other structured identifiers, tools like the swift code validator handle banking codes in a similar fashion.

Common mistakes when working with GUIDs

Several pitfalls cause validation failures in production systems:

• Wrong length: A GUID must be exactly 128 bits (32 hex characters). Truncated or padded strings will fail.
• Invalid characters: Only hexadecimal digits (0-9, a-f) are allowed. Letters g through z are not valid.
• Confusing GUID with UUID: Technically they are the same 128-bit structure. Microsoft historically used the term GUID, while IETF standards use UUID. This guid validator handles both interchangeably.
• Ignoring the nil value: 00000000-0000-0000-0000-000000000000 is structurally valid but represents a special nil identifier. Systems should treat it separately from real generated values.

Worked examples