UUID Validator
UUID validator online free. Check if UUID is valid, detect version (v1-v7), and get detailed error explanations. Validate UUID format instantly.
Enter UUID
UUID Versions Reference
Features
- Validate any UUID (with or without hyphens) in real time
- Detect UUID version (v1 through v7) and display version-specific description
- Detailed anatomy breakdown: time_low, time_mid, time_hi_version, clock_seq, node
- Specific error messages: wrong length, invalid characters, misplaced hyphens, bad variant bits
- Reference table of all UUID versions v1–v7 with descriptions
- Sample UUIDs for quick testing (valid v4, valid v7, invalid)
Common Use Cases
- Validate user-submitted UUIDs in form inputs or API requests
- Debug UUID parsing errors in backend logs
- Determine which UUID version an ID is without reading the spec
- Verify that a UUID has the correct format after decoding from a QR code or OCR
- Check handoff between systems to ensure ID format consistency
UUID Structure & Versions
A UUID is a 128-bit value structured as: 8-4-4-4-12 hexadecimal digits separated by hyphens (36 characters total).
- Bits 49–52 (M field): Version number (1–7)
- Bits 65–66 (N field): Variant bits — must be
10xx(binary) for RFC 4122, meaning the high nibble of the N group is 8, 9, a, or b
Common versions: v1 (timestamp + MAC address, legacy), v3 (MD5 name-based), v4 (random), v5 (SHA-1 name-based), v7 (Unix epoch timestamp, modern). Versions 2 and 6 are niche. Version 8 (free-form) is draft status.
Examples
550e8400-e29b-41d4-a716-446655440000018e5c4c-8b3a-7000-8000-000000000001550e8400-e29b-41d4-ZZZZ-446655440000550e8400e29b41d4a716446655440000Frequently Asked Questions
Look at the 13th character (first character of the 3rd group). This is the version digit: 4 for v4, 7 for v7, 1 for v1, etc. The validator detects this automatically and shows the version name and description.
Structurally, the hyphen-free form (32 hex characters) is a valid UUID representation — it is the same 128-bit value without formatting. Whether a specific system accepts it depends on implementation. This validator handles both formats gracefully.
The variant field occupies bits 65–66 of the UUID. RFC 4122 UUIDs use the binary pattern 10xx, meaning the 17th character (first of the 4th group) must be 8, 9, a, or b. Other variants (NCS, Microsoft COM) exist but are legacy or Microsoft-specific. If the validator says "Invalid variant bits," the 17th character falls outside this range.
Technically, any UUID that passes format validation could be intentionally constructed to be identical to another. The uniqueness guarantee only applies to randomly generated v4 UUIDs (122 bits of randomness makes collisions practically impossible). Name-based UUIDs (v3, v5) derived from the same input will always produce the same UUID by design.
The anatomy section maps each hyphen-separated group to its RFC 4122 field: time_low (32 bits), time_mid (16 bits), time_hi_version (16 bits, includes version), clock_seq_hi_reserved + clock_seq_low (16 bits, includes variant), and node (48 bits, originally MAC address). In v4 UUIDs, most fields are random except the version and variant bits.
💡 Tips
- Paste a UUID from your logs or database directly — the validator handles leading/trailing whitespace automatically.
- If validating UUIDs in production code, use a battle-tested library like the <code>uuid</code> npm package rather than a hand-rolled regex.
- For v3 and v5 UUIDs, the same namespace + name input always produces the same UUID — this is by design, not a bug.
- The variant byte (17th character) must be 8, 9, a, or b. If you see validation failures for otherwise-correct-looking UUIDs, check this character first.
- When debugging UUID issues across microservices, check whether each service produces the same version — mixing v1 and v4 in the same field can cause subtle bugs.