🪪 UUID Validator

🔧 Operation

📝 UUID string

Hyphenated, 32-hex, braced {...}, or urn:uuid:... all accepted.

📝 Two UUIDs to compare

📝 Batch UUIDs (1 per line, ≤1,000)

Newlines, commas, semicolons, or whitespace work as separators.

📤 Result

VALID — {{ singleResult.normalized }}
{{ line.label }} {{ line.value }}
INVALID — {{ singleResult.reason }}
a: {{ compareResult.a }}
b: {{ compareResult.b }}
equal (raw) {{ compareResult.equal }}
equal (normalised) {{ compareResult.equalNormalized }}
count: {{ batchResult.count }}, valid: {{ batchResult.valid }}, invalid: {{ batchResult.invalid }}
#
Input
Valid
v
Variant / reason
{{ row.index }}
{{ row.input }}
{{ row.valid ? "yes" : "no" }}
{{ row.version }}
{{ row.valid ? row.variant : row.reason }}
Enter a UUID and the result will appear here.
⚠️

ℹ️ About UUID Validator

Validation coverage

The UUID Validator is an online UUID format checker, GUID validator, and UUID v7 timestamp decoder. It verifies that a string is a well-formed Universally Unique Identifier and extracts the structural fields the specs encode in those 128 bits: the version, the variant, the special-case Nil and Max identifiers, and — for time-based versions — the embedded timestamp, node, and clock sequence. It does not generate new UUIDs; use the dedicated UUID Generator for that.

The browser UI runs locally, which is useful when request IDs, database keys, or trace IDs are sensitive. The same TypeScript logic module is used server-side via the API endpoint below, so the browser and the server agree byte-for-byte on what counts as a valid UUID.

  • Validate — accept the canonical hyphenated form, the 32-hex no-dash form, braced {...} Microsoft GUID form, or the urn:uuid: prefixed form (any case).
  • Identify — same checks as Validate, with focus on extracting the embedded data for v1, v6, and v7 (the three time-based versions).
  • Compare — check whether two UUIDs are equal raw and after normalisation (case folding, dash stripping, brace stripping).
  • Batch validate — paste up to 1,000 UUIDs and get a count of valid/invalid plus a row-by-row report.

UUID versions at a glance

  • v1 — time-based (Gregorian 100-ns ticks since 1582-10-15 UTC) + 48-bit node identifier (often a MAC address) + 14-bit clock sequence. Defined in RFC 4122 §4.1.4.
  • v2 — DCE Security variant. Rarely used outside legacy systems.
  • v3 — name-based, MD5 hash of a namespace + name. Deterministic.
  • v4 — fully random (122 bits of entropy). The default everywhere.
  • v5 — name-based, SHA-1 hash of a namespace + name. Deterministic, preferred over v3.
  • v6 — reordered v1 layout so the timestamp prefix sorts lexicographically. New in RFC 9562 (2024).
  • v7 — 48-bit Unix-millisecond prefix + 74 bits of random. Sortable, database-friendly. Recommended for new systems. RFC 9562 §5.7.
  • v8 — vendor-defined / experimental. The version field is set to 8 and the rest is opaque.

Variant bits (RFC 4122 §4.1.1, RFC 9562 §4.1)

The two most-significant bits of byte 8 (the 9th hex pair) tell you which UUID family you're looking at:

Bit pattern Variant Use
0xxxNCSApollo Network Computing System (legacy)
10xxRFC 4122Standard UUIDs (and RFC 9562 v6/v7/v8)
110xMicrosoftMicrosoft GUID reserved
111xReservedReserved for future definition

Nil and Max — RFC 9562 §5.9 and §5.10

  • Nil UUID — all 128 bits are zero (00000000-0000-0000-0000-000000000000). Used as a sentinel "no UUID" value. The validator flags isNil: true and does not attempt to decode a timestamp.
  • Max UUID — all 128 bits are one (ffffffff-ffff-ffff-ffff-ffffffffffff). Sentinel "greatest possible UUID". The validator flags isMax: true and also skips timestamp decoding.

How v1, v6, and v7 timestamps decode

  • v1 (RFC 4122 §4.1.4) — the 60-bit timestamp is split across time_low (octets 0–3), time_mid (4–5), and the low 12 bits of time_hi_and_version (6–7). The unit is 100-nanosecond ticks since 1582-10-15 00:00:00 UTC (the Gregorian-reform epoch). Subtract 0x01b21dd213814000 (122192928000000000 ticks) and divide by 10,000 to get Unix milliseconds.
  • v6 (RFC 9562 §5.6) — same timestamp unit and epoch as v1, but the bytes are reordered so the high-order bits land first. The validator rebuilds the 60-bit count from octets 0–7 (with the version nibble masked out) and applies the same Gregorian-to-Unix conversion.
  • v7 (RFC 9562 §5.7) — the first 48 bits encode Unix milliseconds directly, big-endian. No conversion is needed; the validator reads octets 0–5 as a single 48-bit integer.

Use cases

  • Debugging logs — confirm a request-ID string is a real UUID and recover the time it was minted (v1/v6/v7) without crawling a separate timestamp column.
  • Schema validation — verify a CSV / JSON import contains well-formed UUIDs before loading them into a column with a strict UUID type.
  • ETL pipelines — strip braces / URN prefixes and re-emit the canonical lower-case hyphenated form so downstream joins match on bytes, not on incidental formatting differences.
  • API testing — spot the difference between a Nil UUID returned as a "not found" sentinel and a real identifier.
  • Forensics — given a v1 UUID, recover the MAC address (node field) used by the original generator, which can be a lead even decades later.

Accepted input formats

All four shapes resolve to the same 128-bit value:

  • 550e8400-e29b-41d4-a716-446655440000 — canonical hyphenated (RFC 4122 §3)
  • 550e8400e29b41d4a716446655440000 — 32 hex characters, no dashes
  • {550e8400-e29b-41d4-a716-446655440000} — braced Microsoft GUID
  • urn:uuid:550e8400-e29b-41d4-a716-446655440000 — RFC 4122 §3 URN form

Mixed case is accepted; surrounding whitespace is trimmed.

Example validation results

  • 550e8400-e29b-41d4-a716-446655440000 normalises to lower-case canonical form, reports version 4, and has no embedded timestamp to decode.
  • 00000000-0000-0000-0000-000000000000 is structurally valid but flagged as the Nil UUID sentinel, not as a generated application identifier.
  • ffffffff-ffff-ffff-ffff-ffffffffffff is the RFC 9562 Max UUID sentinel and is useful for range checks, but it is not a normal generated UUID.
  • A v7 UUID passes only when the version nibble is 7, the variant bits are in the RFC family, and the first 48 bits can be read as Unix milliseconds.

Version, variant, and uniqueness limits

  • A valid UUID string is not proof that the referenced object exists, belongs to your system, or was generated by a trusted component.
  • v1 and v6 timestamps reflect the generator clock; they are useful clues, not tamper-proof audit evidence. The node field can be a real MAC address, a random node value, or a privacy-preserving value.
  • v2 DCE Security UUIDs are recognised structurally, but their local identifier fields are legacy and not decoded by this page.
  • v8 UUIDs are intentionally application-defined. The validator can identify the version and variant, but it cannot interpret vendor-specific payload bits.
  • Random v4 UUIDs are checked for structure and variant/version bits; this tool cannot prove that the random source had full entropy or that the value is globally unique.

References

  • RFC 9562 — Universally Unique IDentifiers (UUIDs). Defines the current UUID layout, v6, v7, v8, Nil UUID, Max UUID, and canonical string form.
  • RFC 4122 — Legacy UUID URN namespace specification for v1–v5, still useful when validating older systems and documentation.
  • IANA URN namespaces registry — Registry entry for namespace identifiers such as uuid.
  • Microsoft GUID structure — Official GUID field layout used by Windows APIs.

API Usage Example:

POST /api/tools/data/uuid-validator
Content-Type: application/json

{
    "operation": "validate",
    "input": "550e8400-e29b-41d4-a716-446655440000"
}
Ready