UUID Validator & Parser
Validate UUIDs against the real RFC 4122 / RFC 9562 rules, decode every field — version, variant, timestamps, node — and bulk-check whole lists with duplicate detection. 100% in your browser.
Paste a single UUID to see exactly what is inside it: which version it is, which variant, what each of the five hex groups contains, and — for time-based versions — the creation date hidden in the bits. Or paste a whole list (one per line, comma- or space-separated, or a JSON array) to validate in bulk, spot duplicates, and export the results as CSV or JSON. Pairs with the UUID Generator for the other half of the job.
Inspect a single UUID
Paste one UUID — hyphens optional, any case, braces, quotes and urn:uuid: prefixes
are handled. It is validated and parsed live as you type.
Component fields
A UUID is 128 bits laid out as five groups of hex digits. Here is exactly what each field of this UUID contains:
| Field | Bits | Value | Meaning |
|---|
Bit map
All 128 bits, left to right, colour-coded by field:
Normalised forms
The same UUID in the shapes different systems expect. Copy the one your consumer wants:
Bulk validation
Paste any number of UUIDs — one per line, or separated by spaces, commas or semicolons. A JSON array of strings works too. Analysis runs live as you type (up to 5,000 entries).
How the validation works
A string is only a valid RFC 4122 UUID if it passes three independent checks. This tool runs all three and tells you which one failed — so a “no” comes with a reason, not a shrug:
- Shape. Exactly 32 hex digits, conventionally written as five groups of
8-4-4-4-12. Hyphens, case, surrounding braces, quotes and aurn:uuid:prefix are cosmetic and are normalised away before the check. - Version. The 13th hex digit must be a defined version: 1, 3, 4 or 5 (RFC 4122), 2 (deprecated DCE security), 6 or 7 (RFC 9562 time-ordered), or 8 (custom). The all-zero (nil) and all-one (max) UUIDs are reserved sentinels.
- Variant. The 17th hex digit encodes the top three bits of the variant field.
8/9/a/bis the RFC 4122 variant;c/dis the Microsoft legacy variant; the other values are reserved.
The results use three states, because real-world data is messier than a binary pass/fail:
- ✓ valid — passes all three checks. This is a genuine RFC 4122 / 9562 UUID.
- ⚠ warning — the 32-hex shape is right but
the version or variant bits are non-standard (e.g. a Microsoft GUID with variant bits
110, or a 128-bit value with version nibble0). It will parse and round-trip, but code that assumes RFC 4122 semantics may misbehave. - ✗ invalid — wrong length or non-hex characters. Not a UUID in any sense.
The versions, decoded
| Version | How it's built | What the parser shows you |
|---|---|---|
| 0 (nil) | All 128 bits zero | The reserved “no identifier” sentinel — flagged, never generated |
| max | All 128 bits one | The reserved sentinel (inverse of nil, RFC 9562 §5.10) — flagged like nil |
| 1 | 100 ns timestamp since 1582-10-15 + 14-bit clock sequence + 48-bit node | The creation date (UTC + local), the raw 100 ns tick count, and the node as a MAC address with its multicast bit |
| 2 | DCE security UUID (embedded POSIX UID/GID) | Flagged as deprecated — you almost certainly do not have one of these |
| 3 | MD5 hash of a namespace + name | Hash fields; the same namespace+name always yields the same UUID (deterministic) |
| 4 | 122 random bits | Random fields + version/variant nibbles; the general-purpose default |
| 5 | SHA-1 hash of a namespace + name | Hash fields; deterministic like v3 but collision-resistant |
| 6 | v1’s 100 ns Gregorian timestamp, re-ordered most-significant-first so it sorts by time | The creation date decoded from the 100 ns timestamp (same 1582 epoch as v1) |
| 7 | 48-bit Unix-millisecond timestamp + 74 random bits | The Unix millisecond timestamp decoded to a date — the modern database primary key |
| 8 | Custom / vendor-defined (RFC 9562) | Three vendor-defined blocks (48 + 12 + 62 bits) around the version and variant nibbles |
The variant field
The variant is encoded in the top three bits of the third group (the 17th hex digit). It tells other software how to read the rest of the UUID:
| Top 3 bits | 17th hex digit | Meaning |
|---|---|---|
0xx | 0–7 | NCS backward-compatible — pre-RFC legacy |
10x | 8, 9, a, b | RFC 4122 — the one you want |
110 | c, d | Microsoft (GUID) legacy |
111 | e, f | Reserved for future definition |
Note the asymmetry: a v4 UUID with variant 10 is valid, but the same 128 bits with the
variant bits 110 (17th digit c or d) is a Microsoft GUID — the tool
flags it as a warning rather than silently passing it, because interop bugs usually start exactly there.
Common pitfalls when validating UUIDs
- Case and punctuation are cosmetic.
{8-4-4-4-12}in UPPERCASE with braces is the same UUID as lowercase with hyphens. Normalise before comparing — this tool does it for you and shows the canonical form. - 32 characters vs 36. Without hyphens a UUID is 32 hex digits; with them, 36 characters. Both are accepted here; truncating to “short” IDs is not — every hex digit carries entropy.
- GUID ≠ UUID (sometimes). Microsoft's GUID is the same 128-bit format, but older .NET code writes the first three groups little-endian and often uses the Microsoft variant (17th digit
cord). If your data came from COM/ActiveX, expect warnings. - The nil UUID sneaks into logs.
00000000-0000-0000-0000-000000000000usually means “no ID was set” — a bug, not a value. Its all-ones twin, the max UUIDffffffff-ffff-ffff-ffff-ffffffffffff, is rarer but equally reserved. Both are valid by definition, so this tool flags them distinctly instead of hiding them. - v1 timestamps are readable. Anyone holding a v1 UUID can read when it was created and the node it was created on. If that metadata is sensitive, use v4 or v7 (v7 still leaks the creation time, just coarser).
- Version 4 is not sortable. If your validation is really “is this a usable primary key”, you may also want to check the version — v4 keys fragment B-tree indexes; v7 does not.
Need to generate them instead?
This tool inspects UUIDs; the UUID Generator mints them — crypto-secure v4, time-ordered v7 and legacy v1 in bulk, with the same privacy guarantee. Generate a batch there, paste it back here, and verify exactly what you shipped.
Nothing on this page leaves your browser: validation, parsing, duplicate detection, copying and downloading all happen locally, with no server round-trip and no storage of any kind.
Suggested
