UUID Validator (v1–v8, Detect Version)

A UUID looks like 550e8400-e29b-41d4-a716-446655440000 — 36 characters, hyphenated, hexadecimal. But not every 36-character hex string is a valid UUID, and there are eight different UUID versions, each with different semantics (random, timestamp, namespace-hash, sortable). This tool checks the format, identifies the version and variant, decodes the embedded timestamp where one exists, and flags Nil and Max UUIDs.

How to use the UUID Validator (v1–v8, Detect Version)

Paste one UUID per line. For each, the tool checks the hyphenation pattern, version digit (the first character after the 2nd hyphen), variant bits, and structure. If it's a v1 (Gregorian timestamp), v6 (reordered v1), or v7 (Unix ms timestamp), the embedded timestamp is decoded. If it's the Nil (all zeros) or Max (all ones) UUID, the tool flags that — those are valid but special-purpose.

About UUID Validator (v1–v8, Detect Version)

UUIDs (Universally Unique Identifiers) are 128-bit values intended to be unique across space and time without coordination. Eight versions exist, defined by RFC 4122 (1–5) and RFC 9562 (6–8):

  • v1 — Timestamp + MAC address. Leaks the host MAC and creation time. Rarely used today.
  • v3 — MD5 hash of (namespace + name). Deterministic. Same input → same UUID.
  • v4 — 122 random bits. Most common. uuidgen, crypto.randomUUID(), most language stdlibs.
  • v5 — SHA-1 hash of (namespace + name). Same as v3 but with SHA-1 instead of MD5.
  • v6 — Reordered v1 (timestamp in big-endian). Sortable by creation time. Not widely used.
  • v7 — 48-bit Unix ms timestamp + 74 random bits. Sortable + random. Recommended for new database PKs. (See our UUIDv7 generator.)
  • v8 — Custom / implementation-defined. Lets you fit your own data into the UUID format.

The variant field (bits 64-65) distinguishes RFC 4122 UUIDs (variant = 10) from older formats (Microsoft GUID variant = 11, NCS = 0x). Almost every UUID you encounter is variant 10.

The Nil UUID (00000000-0000-0000-0000-000000000000) and Max UUID (all Fs) are reserved sentinel values — valid format but explicitly defined as "no UUID assigned" and "the highest possible UUID" respectively.

Common use cases

  • Debugging — figuring out which library produced a mysterious UUID in your logs (v1 leaks the timestamp, v7 reveals the millisecond of creation).
  • Database migrations — checking if a column is consistently using v4 random UUIDs vs a mix.
  • Security audit — flagging v1 UUIDs in user-facing identifiers (they leak host info and creation time).
  • API integration — verifying that a third-party service returns RFC 4122 UUIDs, not GUIDs or arbitrary tokens.
  • Testing — pasting a list of seed-data UUIDs to confirm versions are what you expect.

Frequently asked questions

What's the difference between UUID and GUID?
GUID is Microsoft's name for the same 128-bit identifier, historically with a different variant bit pattern. Most modern .NET libraries emit RFC 4122 variant 10 UUIDs.

Are uppercase / lowercase letters both valid?
Yes — case is irrelevant. RFC 4122 specifies output as lowercase but accepts uppercase as input.

Can the same UUID be generated twice?
For v4 with proper randomness, the probability is negligible (1 in 2^122). For v1 with MAC + timestamp, theoretically only if the same machine generates two UUIDs in the same 100-nanosecond tick. v3 / v5 are deterministic, so colliding for the same input is expected.

How accurate is the timestamp from v1?
100-nanosecond intervals since 1582-10-15 (the Gregorian reform). Most implementations have ~ms precision in practice.

Why is the Nil UUID valid?
RFC 4122 reserves it as a "no UUID" sentinel. Many DBs use it as a default. The Max UUID was added by RFC 9562 for the opposite purpose ("greater than any UUID").