Random version 4 and time-ordered version 7 UUIDs, singly or in bulk, formatted for code, JSON, or SQL, plus a decoder for any UUID you paste.
| Nil UUID | 00000000-0000-0000-0000-000000000000 |
| Max UUID | ffffffff-ffff-ffff-ffff-ffffffffffff |
| Canonical form | – |
| Version | – |
| Variant | – |
| Embedded timestamp | – |
| Raw hex | – |
| Random bits | – |
This UUID generator produces universally unique identifiers in the two versions modern systems use: version 4, which is 122 bits of cryptographically secure randomness, and version 7, the RFC 9562 format whose first 48 bits are a Unix millisecond timestamp so that identifiers sort in creation order and make good database primary keys. Generate a single UUID or a batch of up to 500, format them in uppercase, without hyphens, wrapped in braces, as a JSON array, or as a quoted SQL IN list, then copy or download the result. A decoder panel takes any UUID you paste and reports whether it is valid, its version and variant, and for time-based versions 1, 6, and 7 the embedded timestamp as a readable date. The nil and max UUIDs are listed for reference. It is for developers seeding databases, writing fixtures and tests, filling in configuration files, and checking what kind of identifier a system handed them.
A UUID is 128 bits shown as 32 hexadecimal digits in 8-4-4-4-12 groups. Four bits at the start of the third group hold the version and the top two bits of the fourth group hold the variant (binary 10 for the RFC 4122/9562 family). Version 4 takes 16 random bytes from the browser's crypto.getRandomValues, then overwrites the version nibble with 4 and the variant bits with 10, leaving 122 random bits and roughly a 50% chance of a single collision only after generating 2.7 × 10^18 values. Version 7 writes the current Unix time in milliseconds into the first 48 bits big-endian, sets the version nibble to 7, fills the remaining 12 bits of the third group with a random counter that increments for identifiers created in the same millisecond (RFC 9562 section 6.2 method 1) so a batch stays strictly ordered, and fills the last 62 bits with random data. The decoder reverses this: it reads the version nibble, classifies the variant bits, and for versions 1 and 6 converts the 60-bit count of 100-nanosecond intervals since 15 October 1582 to Unix time by subtracting 0x01B21DD213814000 and dividing by 10,000.
Use v7 for database primary keys and anything that gets indexed or sorted by creation time: because the leading bits are a timestamp, new rows land at the end of a B-tree index instead of at random positions, which reduces page splits and cache misses in PostgreSQL, MySQL, and SQL Server. Use v4 when the identifier must not reveal when it was created, such as session tokens, password-reset links, or public-facing IDs where creation time is sensitive. Both are unique in practice; the difference is ordering versus opacity.
Version 4 UUIDs here use crypto.getRandomValues, the browser's cryptographically secure random source, not Math.random, so 122 random bits give a collision probability that is negligible at any realistic scale (you would need to generate about a billion UUIDs per second for 85 years to reach a 50% chance of one duplicate). They are unpredictable enough for most identifiers, but a UUID is only 122 bits and is often logged and shared, so for secrets such as API keys or session tokens generate a dedicated random token instead.
The nil UUID is all zeros (00000000-0000-0000-0000-000000000000) and the max UUID, added in RFC 9562, is all ones (ffffffff-ffff-ffff-ffff-ffffffffffff). Neither has a version or variant; they are sentinels for an absent or placeholder value and for the upper bound of a range scan. Do not use the nil UUID as a real key, since many systems treat it as missing, and beware that some libraries reject it as invalid.
Version 1 embeds a 60-bit timestamp and the machine's MAC address, which leaks hardware identity, so it fell out of favor; version 6 is the same data reordered so it sorts by time, offered by RFC 9562 mainly for migrating v1 systems. Versions 3 and 5 are deterministic, hashing a namespace and a name with MD5 or SHA-1, which is useful when the same input must always give the same ID. Version 8 is reserved for custom, application-defined layouts. This page generates v4 and v7 and decodes the timestamp from v1, v6, and v7.
JSON Formatter · Base64 Encode / Decode · URL Encode / Decode · Regex Tester · Hash Generator · JWT Decoder · HTML Entity Encoder · Color Converter · Password Generator · Number Base Converter · QR Code Generator · Chmod Calculator
Browse all Developer Tools, or go back to every free tool on HeroYears.