Text structure
Confirm the exact wrapper, number of hexadecimal digits, and hyphen positions. A substring match is not enough; the entire value must be consumed.
Parse before you trust a regex
Validate UUID structure, version, and variant
Strict mode accepts only the ordinary 8-4-4-4-12 form. Normalize mode intentionally unwraps compact, braced, and urn:uuid: presentation before reporting one normalized lowercase standard value.
Loading the UUID validator…
Enable JavaScript to inspect UUID structure, normalize text, and decode version 7 timestamps.
One value or a batch
How to validate a UUID
- 1
Choose the input policy
Select Strict when a protocol requires standard hyphenated text. Select Normalize when your ingestion boundary deliberately accepts braces, compact hexadecimal text, or a UUID URN.
- 2
Paste the values
Enter one UUID per line, comma-separated values, or a JSON array of strings. The checker examines up to 10,000 values and keeps the text in this browser tab.
- 3
Read the diagnosis
Review normalized text, version, variant, special-value status, and v7 time. Fix the producer rather than silently normalizing when exact wire syntax is part of the contract.
Acceptance policy is part of validation
Strict UUID validation vs normalized input
Strict mode requires 32 hexadecimal digits in five groups of 8, 4, 4, 4, and 12 characters separated by four hyphens. Letter case may be upper, lower, or mixed because RFC hexadecimal text is case-insensitive. Leading or trailing whitespace, braces, a URN prefix, missing hyphens, extra punctuation, and malformed group boundaries are rejected.
Normalize mode accepts a deliberately limited set of common presentation wrappers: the standard form, 32 compact hexadecimal digits, one matching pair of braces around a standard value, or a case-insensitive urn:uuid: prefix followed by the standard value. It then reports the same standard lowercase form. This mode is useful at human input boundaries, but it should not be described as strict protocol validation.
Do not make a parser permissive merely because an example can be repaired. A signed message, database constraint, cache key, routing rule, or interoperable wire format may require one exact representation. Apply normalization before signing only when the governing protocol defines that transformation, and retain the original input if audit or error reporting needs it.
- Strict accepted
919108f7-52d1-4320-9bac-f847db4148a8- Normalize accepted
{919108F7-52D1-4320-9BAC-F847DB4148A8}- Normalize accepted
urn:uuid:919108f7-52d1-4320-9bac-f847db4148a8- Always rejected
- Non-hex characters, mismatched wrappers, missing digits, or extra suffix data.
Four separate questions
What a complete UUID checker validates
128-bit value
Decode exactly sixteen octets in network byte order. The same bytes can be presented with different permitted letter case or optional application wrappers.
Variant and version
Read the high bits of octets 8 and 6 rather than guessing from length. RFC versions use the 10 variant and version values 1 through 8.
Version-specific meaning
Only decode a v7 Unix timestamp after confirming version 7. Nil and Max are special all-zero and all-one UUIDs, not ordinary generated version values.
Fix the actual failure
Common invalid UUID errors
ProblemExampleWhat to check
Wrong length
123e4567-e89b-12d3-a456The value is truncated. A standard UUID needs 32 hexadecimal digits plus four hyphens.Bad character
…-g456-…g is outside hexadecimal 0-9 and A-F. Check copying, OCR, or an incorrect source encoding.Hyphen misplaced
123e4567e89b-…Strict text requires boundaries after 8, 12, 16, and 20 hex digits.Wrapper not allowed
{123e…}Use Normalize only if the receiving boundary intentionally permits a braced GUID presentation.Wrong version
…-4xxx-…The structure may be a valid UUID v4 but invalid for a field specifically requiring UUID v7.Wrong variant
fourth group starts with cThat is Microsoft-reserved variant space, not the RFC 10 variant used by UUID versions 1-8.Bits, not labels
How UUID version and variant detection works
The version is stored in the most significant four bits of octet 6, visible as the first hexadecimal character in group three of standard text. RFC 9562 defines versions 1 through 8 for the RFC variant. A value beginning its third group with 4 carries the v4 version field; 7 carries v7. That field describes layout, not whether the value came from a trustworthy generator.
The variant begins with a variable number of high bits in octet 8. Values whose fourth group begins with hexadecimal 8, 9, A, or B all begin with binary 10, the variant used by the current RFC. A leading 0 through 7 is NCS-reserved space, C or D is Microsoft-reserved space, and E or F is reserved for future definition.
Nil and Max require special handling. The Nil UUID is all zero bits and the Max UUID is all one bits. Their variant bit patterns fall in reserved ranges, but RFC 9562 defines them as special values. A generic checker should report them accurately; a field that requires a generated v4 or v7 should reject them for not being that required version.
- Versions 1-8
- Read from the high four bits of octet 6 for the RFC variant.
- RFC variant
- Fourth group begins with 8, 9, A, or B.
- Nil
00000000-0000-0000-0000-000000000000- Max
ffffffff-ffff-ffff-ffff-ffffffffffff
Timestamp inspection after structural validation
Decode a UUID v7 timestamp
After confirming RFC variant and version 7, interpret the first six bytes as an unsigned big-endian Unix millisecond value. RFC 9562’s Appendix A.6 example begins with hexadecimal 017f22e279b0, which equals decimal 1645557742000 and formats as 2022-02-22T19:22:22.000Z.
The inspector reports this value in UTC. It does not infer a local timezone because the UUID contains an epoch instant, not a zone name or offset. It also does not claim the timestamp is accurate or authentic: system clocks can be wrong, implementations may alter time according to the RFC’s timestamp guidance, and any caller can construct arbitrary UUID bits.
Use the embedded time for debugging, approximate ordering, or format inspection. Keep trusted application timestamps for access control, expiration, audit, billing, compliance, or event semantics. For generation details and monotonicity limits, open the UUID v7 Generator.
RFC v7 test vector
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
Timestamp: 1645557742000
UTC: 2022-02-22T19:22:22.000Z
Syntax patterns have a limited job
Why one UUID regex is not the whole validator
A regular expression can enforce the standard text width and group positions. A version-specific pattern can also require 4 or 7 in group three and [89ab] in group four. That is useful at a form boundary, but it does not decode bytes, identify every variant, recognize the semantic role of Nil and Max, extract v7 time, or prove how the ID was generated.
Patterns also become misleading when they are not anchored. A search regex can find a valid-looking UUID inside a larger malicious or malformed string while the application assumes it validated the entire field. Unicode character classes, whitespace trimming, wrapper handling, and case rules should be chosen explicitly rather than inherited accidentally from a generic library pattern.
For application code, prefer a well-maintained UUID parser that documents supported versions and RFC 9562 behavior. Validate the surrounding contract after parsing: permitted version, required non-Nil value, tenant or database existence, ownership, authorization, and any business constraint are separate checks.
- Regex can check
- Whole-string character count, hex alphabet, group positions, selected visible version and variant nibbles.
- Parsing can add
- Exact bytes, variant classification, version, special values, normalization, and v7 timestamp.
- Application must add
- Existence, uniqueness constraints, ownership, authenticity, authorization, and domain rules.
A valid shape proves only a valid shape
What UUID validation cannot prove
Not guaranteed unique
Syntax cannot search every generated value or your database. Enforce unique constraints and define conflict behavior where duplicates matter.
Not proof of existence
A caller can construct a structurally valid identifier for a record that does not exist. Query the authoritative data source using proper access controls.
Not proof of authenticity
Version and variant bits are public and easy to set. Use a signature, MAC, authenticated session, or another trusted mechanism when origin matters.
Not authorization
Possessing or guessing an identifier must not grant access to someone else’s resource. Check the authenticated principal and policy on every operation.
Questions answered
UUID validator FAQ
What makes a UUID valid?
That depends on the field’s contract. Generic RFC inspection requires a 128-bit value in an accepted presentation, then reports variant, version, or special Nil/Max status. A field that specifically requires UUID v4 or v7 must additionally require that version and usually the RFC variant.
Are uppercase UUIDs valid?
Yes. RFC 9562 permits upper, lower, or mixed hexadecimal case. LiveParse reports a lowercase standard form for consistent comparison, but case normalization does not change the underlying bytes.
Is a UUID without hyphens valid?
It can be a presentation accepted by a particular application, but it is not the ordinary RFC hex-and-dash text form. Strict mode rejects it. Normalize mode accepts exactly 32 hexadecimal digits and reports the standard hyphenated form.
Can the validator check GUID values in braces?
Yes in Normalize mode. A matching brace pair around a standard 8-4-4-4-12 value is unwrapped and normalized. Strict mode rejects braces so you can enforce a protocol that does not permit them.
How do I tell UUID v4 from v7?
After parsing the full value and confirming the RFC variant, read the high four bits of octet 6. In standard text that is the first hex character of group three: 4 means v4 and 7 means v7.
Why does a UUID start group four with 8, 9, a, or b?
All four digits begin with binary 10, the variant used by RFC 9562 layouts. C or D belongs to Microsoft-reserved variant space, while E or F is reserved for future definition.
Are the Nil and Max UUIDs valid?
RFC 9562 defines both as special UUID values. A generic checker should recognize them. They are not generated UUID v4 or v7 values, so an application field requiring one of those versions should reject them.
Does a valid UUID prove the record exists?
No. It proves only the checked structure and fields. Existence, uniqueness, ownership, authenticity, and authorization require checks against trusted application state.
Are pasted UUIDs uploaded?
No. Parsing, normalization, batch results, and v7 time conversion happen in the current browser tab. Clipboard history, extensions, downloaded output, and other device software remain separate privacy boundaries.