RFC 9562 compliance, cryptographic randomness, database indexing performance, and zero-ingestion architecture.
Understanding the differences in entropy and structure between identifier versions.
| Parameter | UUID v1 | UUID v4 | UUID v7 | Nil UUID |
|---|---|---|---|---|
| UUID Version | v1 (Time & MAC based) | v4 (Random) | v7 (Time-ordered) | Nil (000...000) |
| Entropy Source | System Clock + MAC Address | CSPRNG (Cryptographic PRNG) | Unix Epoch + CSPRNG | None |
| Uniqueness Guarantees | High (if MAC is unique) | Extremely High (random) | Extremely High | None (Special purpose) |
| Database Indexing | Poor (random distribution) | Poor (B-Tree fragmentation) | Excellent (Sortable by time) | N/A |
| Privacy Risk | High (Exposes MAC/Time) | None (Opaque) | Low (Time exposed, opaque) | None |
A UUID is exactly 128 bits. It is represented as 32 hexadecimal digits separated by hyphens (8-4-4-4-12). Despite generating completely random data for v4, bits 60-63 indicate the version, and bits 70-71 indicate the variant.
Our UUID engine executes 100% locally. We utilize your browser's Web Crypto API to harvest OS-level entropy for random numbers. Because generation happens client-side, your IDs are completely isolated from network interception or logging.
A UUID Version V5 is a 128-bit identifier structured according to the latest RFC 9562 (which supersedes the legacy RFC 4122). While simple in representation, the bit-level arrangement is optimized for specific computational requirements—from random entropy to chronological sequence.
The shift to RFC 9562 formally recognized Version 7 (v7) as the new standard for time-series and database primary keys. Unlike the random v4, v7 provides "monotonicity"—the ability to sort UUIDs by their creation time without requiring external metadata, significantly reducing database B-Tree fragmentation.
For a Version 4 or 7 UUID, the probability of a collision is $1$ in $2^122$ (after accounting for version/variant bits). To have a 50% chance of a collision, you would need to generate **1 billion UUIDs per second for 85 years**. This makes them safe for use across disconnected, global distributed systems.
Modern database engines (PostgreSQL, MySQL, SQL Server) rely on indexed B-Trees. When you use a random UUID (v4), new records are inserted at non-sequential locations, causing constant index re-balancing. By using Version 7, the “Time-Ordered” prefix ensures that new records are appended to the end of the index, providing performance parity with traditional integers while keeping the benefits of a global, non-guessable ID.
If you just need a quick UUID for a test case without the architectural deep-dive, use our lightweight generator at MyUtilityBox.com
For bulk generation, high-res data exports, and enterprise labeling protocols, use our professional workspace.
Legacy **Version 1** UUIDs were often criticized because they leaked the machine's MAC address and time of generation—valuable metadata for attackers. Modern security practices dictate the use of Version 4 (Full Random) or Version 7 (Time-Ordered Random), which provide the necessary entropy while masking the underlying hardware details of the generating server.
Quick access to other UUID utilities.
Looking for a faster check or a professional report?