A UUID (Universally Unique Identifier) is a 128-bit value, written as 32 hex digits in the 8-4-4-4-12 pattern, used to label records without a central authority. This tool generates v4 (random) and v7 (time-ordered) UUIDs and validates any UUID, decoding its version, variant, and embedded timestamp.
How it works
A UUID reserves a few bits to describe itself:
- The version lives in the first hex digit of the third group (position 13 in the full string). A
4means random; a7means Unix-time ordered. - The variant lives in the top bits of the fourth group and is almost always
10xx, marking an RFC 4122/9562 UUID. - For v7, the leading 48 bits hold the millisecond timestamp; for v1, the time fields hold 100-nanosecond intervals since 1582.
When generating, v4 calls crypto.randomUUID() and v7 packs Date.now() plus random bytes, setting the version and variant bits explicitly.
UUID versions in the wild
The UUID specification defines several versions, each with a different approach to generating unique values:
v1 — time-based, using the system clock (in 100-nanosecond intervals since October 1582) plus the MAC address of the generating machine’s network interface. Unique and sortable, but leaks the MAC address and real time. Largely replaced by v7 in new systems.
v3 and v5 — name-based, derived by hashing a namespace UUID plus a name using MD5 (v3) or SHA-1 (v5). Given the same namespace and name, these always produce the same UUID. Useful for deterministic IDs where the same input should always produce the same identifier.
v4 — randomly generated. 122 random bits, 6 fixed bits for version/variant. The most commonly used version today. No ordering, no embedded metadata.
v7 — time-ordered random. 48 bits of Unix millisecond timestamp leading the value, then random bits. Because newer IDs always have larger timestamp prefixes, they sort chronologically. This is the version of choice for database primary keys that must be sequential, globally unique, and require no central coordinator.
Nil — all 128 bits zero. A sentinel value meaning “no UUID assigned yet.”
Max — all 128 bits one (all f). Another sentinel, introduced in RFC 9562.
Validating UUIDs from external sources
The validator is useful when you receive a UUID from an API, database, or third-party system and need to understand what version it is and whether it is well-formed. Common scenarios:
- An API returns a resource ID and you want to confirm it is a UUID, not some other identifier format.
- You have v1 UUIDs in a legacy database and want to decode the embedded timestamp to understand when each record was created.
- You are migrating from v1 to v7 and want to verify which format new records are using.
- A system is generating UUIDs that look unusual — the validator will tell you if the version bit is set correctly or if the value is a Nil/Max sentinel.
Worked example
For example, paste 01915f5c-b0d8-7000-a3f2-2a2c9c4d5e6f into the validator. The third group starts with 7, flagging it as a v7 UUID. The leading 48 bits decode to a millisecond timestamp, and the tool shows you the approximate creation time of this ID. The variant nibble in the fourth group (a) confirms it is an RFC 4122/9562 UUID rather than a Microsoft GUID variant.
Tips and notes
Prefer v7 for database keys: because the timestamp leads the value, new rows insert at the end of a B-tree index instead of scattering across it, which keeps writes fast and indexes compact. Use v4 when you want IDs that reveal nothing about creation order or timing.
The validator also recognises the special Nil UUID (all zeros) and Max UUID (all f), which are reserved sentinel values rather than real version-bearing identifiers. All generation and validation runs in your browser; no UUID is uploaded.