How to Validate a UUID Format and Version

The common textual form is:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

• 32 hex digits (0–9, a–f or A–F) plus 4 hyphens in fixed positions (8-4-4-4-12)
• M — the version nibble (1–7 in current practice for standard layouts)
• N — the start of the variant field; RFC 4122 variant uses binary 10xx, so the hex digit is typically 8, 9, a, or b

Acceptable variants of the string

• With or without hyphens (32 continuous hex chars) — many APIs accept both; always know which your system stores
• Uppercase or lowercase hex — usually treated as equal
• Optional braces in some Microsoft contexts: {…}

Invalid examples: wrong group lengths, non-hex characters, only 31 digits, or a “UUID-looking” random string with an illegal version nibble for your policy.

Paste candidates into the free UUID validator before writing custom regex that drifts from the RFC fields. Regex that only checks “36 characters with hyphens” will accept strings whose version nibble is 0 or whose variant bits are wrong — fine for a rough filter, insufficient as your only gate.

Prefer a library or explicit field checks in production code. Use the browser validator when you are triaging a bad ID from a ticket, a log line, or a spreadsheet column and need an answer in seconds.

RFC 4122 defined the classic layout and versions widely deployed in software. Later work (including RFC 9562 updates in the UUID space) documents additional versions such as v6 and v7 that keep the 128-bit size while improving time ordering.

The version is encoded in the high nibble of the third group. The variant marks which bit layout family you are in. Validators that only check “hex + hyphens” miss both fields.

Versions you will actually see

• v1 — time-based with node (often MAC-derived historically); sortable by time with caveats
• v3 / v5 — name-based (MD5 / SHA-1 hash of a namespace + name); deterministic for the same inputs
• v4 — random (most common for new public IDs)
• v6 / v7 — time-ordered designs that play nicer with database indexes than pure random v4
• v2 — DCE security variant; rare in web apps

A string can be format-valid as “UUID-shaped” yet fail a product rule that only allows v4. Policy is separate from syntax. For how random v4 IDs are minted, read the how UUIDs work guide.

Read the structure; do not guess from the first characters alone.

1. Normalize: strip braces/hyphens if needed; lowercase for comparison.
2. Confirm 32 hex digits.
3. Version = nibble at the version position (character index 12 in the continuous hex form, 0-based).
4. Variant = top bits of the next field (continuous index 16). RFC 4122 variant expects the pattern that maps to hex 8–b for the first digit of that group.

Timestamps on time-based versions

v1, v6, and v7 embed time information you can extract for debugging “when was this ID created?” — with the usual caveats about clock skew and generator quality. v4 has no meaningful timestamp in the bits; any “created at” must come from your database column.

The UUID validator surfaces version, variant, and timestamp extraction where applicable so you do not decode fields by hand during an incident.

Name-based v3/v5 tie into hashing of a namespace and name — different problem from validating an existing ID. For general digests, see the hash generator guide.

One bad ID in a migration file or CSV import can fail thousands of rows. Batch mode is for bulk lists, not for replacing database constraints.

• Import pipelines — reject or quarantine rows before insert
• API contract tests — fixture files full of resource IDs
• Log forensics — separate well-formed correlation IDs from garbage tokens
• Migration audits — count how many stored values are v4 vs other versions

What to record per line

Pass/fail, version, variant, and a short reason (bad length, bad hex, wrong version nibble, wrong variant). That report is more useful than a single boolean for a 10,000-line file.

UUIDs often travel inside JSON bodies. Pretty-print and schema-check payloads with the JSON formatter validator and its JSON validation guide when the failure might be structural JSON rather than the UUID field itself.

Run multi-line input through the free UUID validator batch path, then fix generators upstream so bad IDs stop appearing.

These are different jobs.

• Validate when an ID already exists — path params, foreign keys, webhook payloads, user-supplied references. You accept or reject; you do not invent a substitute silently.
• Generate when you create a new resource and need a fresh primary key or correlation ID.

Do not “repair” invalid UUIDs

Padding digits, swapping characters, or forcing a version nibble destroys referential integrity. If the client sent garbage, return 400 with a clear error. If a legacy row is corrupt, fix data with a controlled migration, not ad-hoc string surgery in the request path.

Security note

Validation is not authentication. A well-formed v4 UUID is still a secret only if you treat it as one (unguessable capability URLs). Predictable or leaked IDs need authorization checks, not prettier regex.

Mint new values with the UUID generator or GUID generator; check old values with the UUID validator.

In API design, document whether path parameters must be hyphenated v4 strings, whether you accept uppercase, and whether the NIL UUID is rejected. Clients that pass validation locally but fail in production almost always disagree on one of those three rules.

Most production failures are boring and mechanical.

• Truncation — copy/paste cut the last group
• Extra whitespace or newlines — trim before parse
• Wrong separators — underscores or spaces instead of hyphens
• Non-hex characters — letter G, punctuation, or full-width digits
• NIL UUID confusion — 00000000-0000-0000-0000-000000000000 is format-valid in many parsers but forbidden by some business rules
• Version policy mismatch — string is fine, app only accepts v4
• Binary vs string mix-ups — 16 raw bytes vs 36-char text; endianness issues in some GUID byte layouts

Log the failure class. “invalid_hex” and “unsupported_version” lead to different fixes (client bug vs generator config).

When IDs are embedded in larger documents, validate JSON first with the JSON formatter guide, then field-level UUID checks.

Single string or list — same idea.

1. Open the free UUID validator.
2. Paste one UUID or a batch of IDs (one per line when using batch mode).
3. Review pass/fail and any normalize options (hyphens, case).
4. Read detected version (1–7) and variant when the layout matches.
5. For v1/v6/v7, inspect extracted timestamps if shown.
6. Export or note failures for import cleanup.
7. If you need a replacement ID for a new row, generate separately — do not edit the invalid string.
8. Add the same checks in server code so the browser tool is a debug aid, not the only gate.

Related tools: UUID generator, GUID generator, hash generator for digests, and JSON formatter validator for payloads that carry IDs.