UUID Validator - Validate & Decode UUID Online

How to use this tool

1. Paste a UUID, URN, compact hexadecimal form, or a log line that contains one UUID.
2. Review its normalized form, version, variant, and validity status.
3. For v1, v6, and v7 UUIDs, review the decoded timestamp and any version-specific fields.

UUID Validator and Decoder

Paste a UUID or GUID to check its structure, identify its version and variant, and decode the fields that can be read from its bits. The parser runs in this browser tab. It does not send the UUID to a server or save it in browser storage, which is useful when checking identifiers copied from local logs, test fixtures, or an API response.

UUID versions and their fields

Versions 1 and 6 use a 60-bit timestamp measured in 100-nanosecond intervals from 15 October 1582. Version 1 places the timestamp fields in the original order; version 6 rearranges them so that lexicographic order follows time more naturally. Version 7 stores Unix time in milliseconds in its first 48 bits. The remaining v7 bits are random or generator-defined, so this tool does not guess that they contain extra sub-millisecond time.

Versions 3 and 5 are deterministic name-based UUIDs using MD5 and SHA-1, respectively. Their hashes are one-way: a UUID alone does not reveal the original namespace or name. Version 4 uses 122 random bits and has no timestamp. Version 2 is the DCE Security form, whose clock field includes a local domain identifier. Version 8 leaves its payload to an application. Versions 6, 7, and 8 are defined by RFC 9562; v1 through v5 field layouts are described in RFC 4122.

Accepted input forms

The input accepts the canonical 8-4-4-4-12 hexadecimal form, uppercase letters, 32 compact hexadecimal digits, and a urn:uuid: prefix. One matching pair of braces, parentheses, single quotes, or double quotes is also allowed. If you paste a log line or sentence containing a UUID, the first complete UUID token is extracted and shown so you can see which value was checked. Partial hyphen patterns and mismatched wrappers are rejected. Use the UUID Inspector for a field-by-field layout, or the UUID Generator when you need to create a new identifier.

How validation works

After input normalization, the structural check is the following canonical shape:

/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i

This checks character groups and hyphen positions. It does not force a version or variant into that pattern: those are read separately from the 13th and 17th hexadecimal digits. Defined versions are numbered 1 through 8. Other version nibbles are reported as well-formed with an unknown version instead of being presented as a known UUID version. The all-zero Nil UUID and all-one Max UUID are named reserved sentinels and do not get a made-up version.

Variants and legacy GUIDs

The variant bits are the high bits of the first hexadecimal digit in the fourth group. The common RFC 4122/IETF variant uses 10xx; the validator also identifies the legacy NCS 0xxx and Microsoft 110x patterns. These variants are reported without changing or rejecting the UUID string. A GUID in braces is just a wrapper. Windows COM can store the first three fields in a mixed-endian binary layout, but that storage detail does not change the text value pasted here.

When to validate a UUID

Check identifiers at API boundaries and before inserting text into a UUID-typed database column so malformed input can be rejected with a clear message. A shape check is only one part of an application's policy: decide which versions and variants the application accepts and use a maintained parser configured for those requirements. For example, an API that only issues v4 identifiers may want a stricter rule than a diagnostic tool that needs to inspect older NCS or Microsoft GUIDs.