UUID Validator – Validate & Inspect UUIDs
Check whether a UUID is valid, see its version and variant, and extract the embedded timestamp from time-based UUIDs. Paste one or many UUIDs to validate them in bulk, normalize into canonical, compact, braces, or URN format, and copy or download the results. Free, private, and runs entirely in your browser.
Input
Paste UUIDs to validateResults
Validation resultsWhat does this UUID validator do?
A UUID validator checks whether a string is a syntactically valid universally unique identifier and then explains what it contains. The bare minimum check is format: a UUID is 128 bits, conventionally written as 32 hexadecimal digits in five hyphenated groups. But format alone isn't enough to call a UUID "valid" — the version nibble and variant bits also need to fall within the values defined by the spec.
This tool goes further. For every UUID it parses, it reports the version (v1 through v8) and variant, extracts the embedded timestamp from time-based versions (v1, v6, v7), shows the MAC address and clock sequence for v1 UUIDs, and normalizes the value into every common representation — canonical, uppercase, compact, braces, and URN. If you paste a batch, you get a summary of how many were valid.
Everything runs locally in your browser. The UUIDs you paste never leave your device, there's no signup, and there are no usage limits.
UUID structure, bit by bit
A UUID is a 128-bit value. When written in canonical form xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, the hyphens are purely cosmetic — the 32 hex digits are what matter. The two nibbles shown here as M and N are the version and the first nibble of the variant field.
| Byte | Bits | Meaning |
|---|---|---|
0–3 | time_low | Least significant 32 bits of the timestamp (v1) or the random data (v4). |
4–5 | time_mid | Next 16 bits of the timestamp, or random data. |
6 | version | High nibble is the version number 1–8. The low nibble is part of the time_high field (v1) or random data. |
7 | time_high | Remaining 8 bits of the 12-bit time_high field. |
8 | variant | High 2 bits identify the variant family. The remaining bits are the clock sequence (v1) or random data. |
9 | — | Clock sequence or random data. |
10–15 | node | 48-bit node identifier — usually a MAC address (v1), or random data. |
UUID versions and what they mean
| Version | Name | What it's built from |
|---|---|---|
| 1 | Time-based | 60-bit timestamp since 1582-10-15 + 14-bit clock sequence + 48-bit node (usually a MAC address). |
| 2 | DCE security | Like v1 but with a POSIX UID/GID in place of the time_low field. Almost never used outside legacy DCE. |
| 3 | MD5 name-based | MD5 hash of a namespace UUID and a name. Deterministic: same inputs → same UUID. |
| 4 | Random | 122 bits of cryptographic randomness. The most common version in modern applications. |
| 5 | SHA-1 name-based | SHA-1 hash of a namespace UUID and a name. Deterministic and preferred over v3. |
| 6 | Reordered time | Same data as v1 but with the timestamp fields reordered so the UUID sorts by time. |
| 7 | Unix epoch time | 48-bit Unix millisecond timestamp + 74 random bits. Sortable, and the modern choice for database keys. |
| 8 | Custom | Application-defined. The version field is 8 but the remaining 122 bits follow whatever scheme the app chooses. |
Versions 9 through 15 are reserved for future definition. A UUID that reports one of those version numbers is either produced by an extension or by a buggy generator.
What makes a UUID valid or invalid
There are three levels of "valid" for a UUID, and this tool lets you decide how strict you want to be:
- Syntactic validity. The string has 32 hex characters (with or without hyphens, braces, or a URN prefix), nothing else. Any string that doesn't parse into exactly 128 bits is invalid.
- Version validity. The version nibble is 1 through 8. Version 0 is only valid for the nil UUID (all zeros). Versions 9–15 are reserved and technically invalid.
- Variant validity. The high two bits of byte 8 follow the RFC 4122 pattern (10xx). The NCS, Microsoft, and Future variants use different bit patterns and are unusual to see in modern systems.
When Strict RFC validation is on, both version and variant must match. When it's off, only syntax is required — which matches what most parsers actually enforce. Many UUID generators, including some popular libraries, will happily emit UUIDs with non-RFC variant bits or non-standard versions, and most applications accept them without complaint.
Frequently asked questions
{123e4567-e89b-12d3-a456-426614174000}, and URN-formatted values like urn:uuid:123e4567-e89b-12d3-a456-426614174000. Each of those can be toggled off if you want stricter input.10xx (RFC 4122). Some parsers are lenient about these two fields, which is why this tool exposes a strict mode toggle.10xx will be rejected. That's the correct behavior per RFC 9562, but many systems tolerate non-standard version or variant fields. Turn strict mode off if you only care about the format shape.10xx), which covers all modern UUIDs. Older NCS and Microsoft variants use different bit patterns and are unusual to see today.