UUIDTest — Online UUID Validator, Version Detector & Generator

UUID Validator 100% CLIENT-SIDE

UUID String to Inspect

Validation & Metadata

More from UUIDTest

Bulk UUID Generator (v4 and v7) Generate up to 1,000 UUIDs at once in your browser: random v4, or time-ordered v7 that sorts in creation… Tool UUID Timestamp Decoder (v1, v6, v7) Paste any UUID, hyphenated or not, and read its version, variant and, for v1, v6 and v7, the creation time… Tool

Guides

UUID v4 vs v7

All tools →All 1 guides →

Frequently Asked Questions

Is my data safe on uuidtest.net?

Yes. Validation and generation run in your browser, so identifiers are never uploaded.

How can I tell a UUID v4 from a v7?

Look at the version nibble, the first digit of the third group. v4 has a 4 there and is random; v7 has a 7 and starts with a 48-bit millisecond timestamp, so v7 values sort roughly in creation order.

Is a generated UUID guaranteed unique?

A v4 UUID has 122 random bits, so collisions are astronomically unlikely but not impossible. If ordering matters, prefer v7, which is time-ordered and gives better index locality in databases.

🧭 Pro Tips & Gotchas

What it validates

Shape first: 32 hex digits in 8-4-4-4-12 grouping. The generator path uses crypto.randomUUID(), which is secure-context-only — on plain HTTP it is unavailable, so the generate button needs https:// or localhost.
It then reads the version nibble (the first digit of the third group) and the variant bits (first hex digit of the fourth group), which is what actually distinguishes a real UUID from a random 36-character string.
Variants: 8/9/a/b = RFC 4122 (what you want); 0–7 = NCS, c/d = Microsoft, e/f = the reserved/legacy one.

UUID gotchas

Version 4 means 122 random bits, not 128 — the version and variant nibbles are fixed, which is exactly why this tool can check them. A v4 whose fourth group starts with 3 is not a v4.
v1 is time+MAC and leaks identity and creation time; it is also not monotonic across reboots. Do not use it as a sort key.
v6 reorders the v1 timestamp to be sortable; v7 puts a Unix-ms prefix in front of random bits and is the one to pick for primary keys — B-tree inserts stay append-only, so index fragmentation collapses compared to random v4.
"Uniqueness" claims are version-specific. v7 at high generation rates on one host can collide in the same millisecond without a monotonic counter; v8 is explicitly unstandardised, so treat it as a private format.
Nil UUID (00000000-0000-0000-0000-000000000000) is a valid value meaning "absent". Validation that only checks format will accept it as a real foreign key.
Storage: store as uuid/binary(16), never char(36). The text form wastes 12 bytes per row, kills index locality, and invites case mismatches — compare case-insensitively or normalise on write.
Byte order is the interoperability trap: Postgres, Java, and .NET (Guid.ToByteArray) use mixed-endian layouts, so the same UUID has a different byte sequence in each. Hex text is the safe interchange format.
UUIDs are not secrets and not capability tokens. Their entropy is 122 bits at best and only when generated from a CSPRNG — never derive an auth token from crypto.getRandomValues + manual nibble math when randomUUID() exists.