What is a UUID Version 4?
A UUID Version 4 (Universally Unique Identifier) is a 128-bit identifier generated using cryptographically strong pseudo-random numbers. Defined under Section 4.4 of RFC 4122, UUID v4 is the most ubiquitous unique identifier format used across modern software engineering, web APIs, cloud architectures, and database records.
Unlike Version 1 (which relies on the machine's MAC address and time) or Version 7 (which embeds a millisecond timestamp), UUID v4 is designed to be purely non-deterministic. It provides zero temporal or geographical information, making it ideal for security-sensitive tokens, user IDs, and multi-tenant architectures where timestamp enumeration poses an information leakage risk.
The Anatomy of a 128-Bit UUID v4
A UUID v4 is represented in canonical form as a string of 32 hexadecimal characters divided into 5 groups by hyphens (8-4-4-4-12), for a total of 36 characters:
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
Out of the total 128 bits, 6 bits are strictly reserved by the specification, leaving 122 bits of pure cryptographic randomness:
- Version Bits (4 bits): The 13th character is always fixed to
4(binary0100), signifying that the identifier was generated using the Version 4 random algorithm. - Variant Bits (2 bits): The 17th character (represented by
y) always begins with binary10. In hexadecimal, this character is restricted to one of four values:8,9,a, orb(standard RFC 4122 / Leach-Salz variant). - Random Bits (122 bits): All remaining 30 hexadecimal characters are derived from a cryptographically secure pseudo-random number generator (CSPRNG).
Collision Probability Mathematics
Engineers often ask: "Can two UUID v4 values ever collide?" Mathematically, the probability of a collision is governed by the Birthday Paradox. With 122 bits of true randomness, the total number of unique UUID v4 values is:
2122 = 5,316,911,983,139,663,491,615,158,242,462,444,564 ≈ 5.3 × 1036
To grasp the scale of this number:
| Generated UUIDs | Collision Probability | Practical Real-World Context |
|---|---|---|
| 1 Billion (109) | ~1 in 1019 | Virtually zero (less likely than being struck by a meteorite) |
| 1 Trillion (1012) | ~1 in 1013 | Negligible across global data systems |
| 2.71 Quintillion (2.71 × 1018) | ~1 in 2 (50%) | Generating 1 billion UUIDs every second for 85 continuous years |
Why True CSPRNG Entropy Matters
A critical requirement of RFC 4122 is that the random bits must originate from a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). In web browsers and Node.js environments, standard functions like Math.random() must never be used for UUID generation because they employ linear congruential or xorshift algorithms that are predictable and subject to seed collisions.
Our tool strictly utilizes the browser's native Web Crypto API (window.crypto.randomUUID() and window.crypto.getRandomValues()). This interfaces directly with the operating system's kernel entropy pool (such as /dev/urandom on Linux/macOS or BCryptGenRandom on Windows), guaranteeing absolute unicity and cryptographic unpredictability.
UUID v4 vs UUID v7: Which Should You Use?
The IETF recently published RFC 9562, introducing UUID Version 7. Here is how to choose between v4 and v7 for your software architecture:
- Choose UUID v4 when: You require zero timestamp leakage, maximum security for session identifiers, distributed trace IDs, password reset tokens, or client-side nonces where the creation time should remain strictly private.
- Choose UUID v7 when: You are inserting millions of records into relational database tables (PostgreSQL, MySQL, SQLite, SQL Server) indexed by B-trees. Because v7 contains a millisecond timestamp in its most significant bits, inserts remain sequential, preventing database index fragmentation and page splits.