Paste one UUID per line — up to 50 for batch validation
Samples:
Ready to validate
Paste a UUID and click Validate// validate uuid format & detect version instantly
Validate UUID format instantly, identify version (v1–v5, v7), check variant, and inspect fields — free, browser-based, no sign-up required.
Ready to validate
Paste a UUID and click ValidateEnter one UUID or multiple (one per line) — braces and uppercase are accepted.
Hit the Validate button or press Ctrl+Enter to run the check instantly.
See the version, variant, field breakdown, and alternate formats for each UUID.
The UUID Validator checks whether a string is a valid Universally Unique Identifier and identifies its version (v1–v8, Nil, Max) and variant. All processing happens in your browser — no data is sent to our servers.
This validator supports all standardized versions: v1 (time-based), v2 (DCE Security), v3 (MD5 name-based), v4 (random), v5 (SHA-1 name-based), v6 (reordered time), v7 (Unix timestamp), v8 (custom), plus the special Nil UUID (all zeros) and Max UUID (all ones) defined in RFC 9562.
No — all validation logic runs entirely in your browser using JavaScript and PHP output buffering. Your UUIDs never leave your machine. This makes the tool safe for validating UUIDs that may be linked to sensitive records.
Standard hyphenated format (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), uppercase or lowercase, and braced format ({uuid}) are all accepted. The validator normalizes them before checking.
The version is encoded in the 13th character of the UUID (the first hex digit of the third group). For example, a UUID starting xxxxxxxx-xxxx-4xxx is version 4. The variant is determined by the first 1–3 bits of the 17th character.
Yes — paste up to 50 UUIDs, one per line, and click Validate. Each UUID is checked independently and results are displayed in a compact batch table so you can quickly scan for invalid entries.
A Nil UUID is 00000000-0000-0000-0000-000000000000 — all 128 bits set to zero. It is sometimes used as a sentinel value or placeholder. Its counterpart, the Max UUID (ffffffff-ffff-ffff-ffff-ffffffffffff), was formalized in RFC 9562.
A UUID (Universally Unique Identifier) validator checks whether a given string conforms to the UUID standard format defined in RFC 4122 and its successor RFC 9562. Beyond simple format checking, a good validator also identifies the UUID version — which encodes how the identifier was generated — and the variant, which indicates the standards body that defined the layout.
UUIDs are 128-bit identifiers typically represented as a 32-character hex string split into five groups by hyphens: 8-4-4-4-12. Every database primary key, API resource identifier, session token, and distributed system event ID that uses UUIDs needs to be in this exact format to be interoperable.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and assets — worth checking out.
The version number is one of the most important pieces of information a UUID carries. It tells you how the identifier was created:
The variant field (bits 64–65 of the UUID, encoded as the first 1–3 bits of the 17th hex character) indicates which standard defines the UUID's bit layout:
When you see a UUID with variant "RFC 4122", that is what most developers mean when they say "UUID." Microsoft GUIDs look identical in string form but have different internal byte ordering — important to know when working cross-platform with binary UUID storage.
When validating UUIDs programmatically, these are the most frequent issues developers encounter:
4 as its 13th character. If a UUID claims to be v4 but has a different digit there, something went wrong in generation.UUID v4 has been the industry default for over a decade because it is simple to generate and contains no personally identifiable information. However, UUID v7 is gaining rapidly in popularity for one key reason: database index performance.
When you insert random v4 UUIDs into a B-tree index (such as a PostgreSQL or MySQL primary key), each new row must be inserted at a random position in the index tree, causing frequent page splits and high write amplification. With v7, the Unix millisecond timestamp in the high bits means new UUIDs are always appended near the end of the index — the same access pattern as a sequential integer, but globally unique without a central counter.
If you are starting a new project and need UUID primary keys, UUID v7 is now the recommended choice. For existing systems using v4, migration is rarely worth the disruption — v4 is perfectly correct and will serve you well for decades.
Regex validation is the fastest approach for a format check across all languages. The canonical pattern is /^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i. Note that this pattern validates format and version/variant constraints simultaneously. For a pure format check without version constraints, drop the [1-8] and [89ab] specifics.
Most modern frameworks provide built-in UUID validation: PHP has Ramsey\Uuid, Node.js has the uuid and uuidv7 packages, Python has the built-in uuid module, and Go has github.com/google/uuid. Always prefer a dedicated library over hand-rolled regex in production code — libraries handle edge cases like Nil UUIDs, byte order for binary storage, and version-specific rules.
UUIDs stored as strings (36 chars with hyphens, or 32 chars without) are human-readable but consume more storage and are slower to index than binary representation. A UUID stored as BINARY(16) in MySQL or uuid type in PostgreSQL uses exactly 16 bytes — less than half the storage of a CHAR(36). For high-volume tables with millions of rows, the storage and index size difference is significant.
When converting between string and binary representations, watch out for byte order: RFC 4122 UUIDs in binary use big-endian byte order throughout, while Microsoft GUIDs mix endianness for the first three fields. This is why a GUID generated by .NET and stored as binary may round-trip differently if decoded as an RFC 4122 UUID.