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 V4 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.
A UUID Version 4 is a 128-bit (16-byte) identifier where 122 of those bits are filled with cryptographically secure random data. The remaining 6 bits are fixed by the RFC 9562 specification to encode version and variant metadata. At its core, UUID v4 is simply a structured bucket of randomness — its power comes entirely from the quality and quantity of the entropy it contains.
The 128 bits are serialized into 32 hexadecimal digits and grouped with hyphens into the canonical 8-4-4-4-12 format: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. The 4 in position 13 is the version nibble (always 4 for v4), and they in position 17 must be one of8,9,a, orb — encoding the Leach-Salz variant (binary 10xx).
RFC 9562 (which formally obsoletes RFC 4122 as of April 2024) specifies the exact bit positions for version and variant fields. Every UUID is a 128-bit integer split into five fields by hyphens for human readability. The layout — from most-significant to least-significant byte — is:
| Field | Octet Range | Bits | v4 Content |
|---|---|---|---|
| time_low | 0–3 | 32 | Random |
| time_mid | 4–5 | 16 | Random |
| time_hi_and_version | 6–7 | 16 (4 ver + 12 rand) | 0100 + 12 random bits |
| clock_seq_hi_res | 8 | 8 (2 var + 6 rand) | 10 + 6 random bits |
| clock_seq_low | 9 | 8 | Random |
| node | 10–15 | 48 | Random |
The version nibble is set by OR-masking byte 6 with 0x40 after AND-masking with0x0f. The variant is set by OR-masking byte 8 with0x80 after AND-masking with0x3f — forcing the two most-significant bits of that byte to 10. All other 122 bits remain untouched random data.
crypto.getRandomValues()The Web Cryptography API (window.crypto, now globally available in all modern browsers and Node.js 19+) exposescrypto.getRandomValues(typedArray), which fills a TypedArray with cryptographically strong random values. Unlike Math.random(), which uses a deterministic PRNG unsuitable for security purposes,getRandomValues() draws from the operating system's entropy pool (Linux: /dev/urandom via getrandom(2); Windows: BCryptGenRandom; macOS: SecRandomCopyBytes).
The OS entropy pool is continuously seeded from hardware noise sources: CPU thermal jitter, interrupt timing, disk I/O variance, and where available, a hardware random number generator (HRNG) instruction like Intel's RDRAND or ARM's RNDR. This means every call to getRandomValues() produces output that is computationally indistinguishable from true randomness.
Modern browsers also expose crypto.randomUUID() which is a single native call producing a v4 UUID directly. MyUtilityBox uses this API where available, falling back to the manual byte-manipulation approach above for full cross-browser compatibility.
Shannon entropy quantifies the information content — and therefore the unpredictability — of a random variable. For a perfectly uniform source with N equally-likely outcomes, entropy is H = log₂(N) bits. UUID v4 has 122 random bits, so its entropy is exactly 122 bits. The total keyspace contains 2¹²² ≈ 5.3 × 10³⁶ possible values.
To put 122 bits in perspective: even if every device on Earth (approximately 15 billion connected devices) each generated a UUID every nanosecond, the total generated per year would be roughly 4.7 × 10²⁶ — still a vanishingly small fraction of the 5.3 × 10³⁶ total keyspace. The probability of any collision in that scenario would be approximately 1 in 10¹⁰ — effectively zero.
The Birthday Problem (or Birthday Paradox) states that in a group of just 23 people, there is a 50% probability that two share a birthday — far more than intuition suggests. The same mathematical principle applies to UUID collision probability, and it's the reason we can't simply divide 1 by 2¹²² to get the collision risk.
The approximate probability of at least one collision when generating n UUIDs from a space of N = 2¹²² values is given by the formula:
To reach a 50% probability of collision, you would need to generate approximately n ≈ 2.7 × 10¹⁸ UUIDs — that is, 2.7 quintillion identifiers. At the rate of one billion UUIDs per second, that would take over 85 years of continuous generationto even have a coin-flip chance of seeing a single duplicate.
Probability of collision ≈ 1 in 10²⁴. You would need to run at this rate for longer than the current age of the universe to reach a 1-in-a-billion chance.
50% collision probability requires 85 years. In practice, no application will ever generate that volume from a single UUID v4 source.
UUID v4 is the right default for most application-layer identifiers: session tokens, correlation IDs, object references in NoSQL stores, API keys (when truncated and encoded), and feature flag keys. However, it is not optimal for relational database primary keys.
The root cause is index locality: random v4 UUIDs scatter writes across the entire B-Tree index, causing page splits and cache misses on every insert. UUID v7's millisecond-precision Unix timestamp prefix makes new rows monotonically increasing, effectively giving you integer-like insert performance with the collision safety and non-guessability of a 74-bit random suffix.
Quick access to other UUID utilities.
Looking for a faster check or a professional report?