Toolypet

The Science of Unique Identifiers

128 Bits of Uniqueness

A UUID (Universally Unique Identifier) is a 128-bit number formatted as 32 hex digits in five groups: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M digit indicates the version (4 for random), and N indicates the variant (8, 9, a, or b for RFC 4122). Version 4 UUIDs use 122 random bits, providing 5.3 × 10³⁶possible values — more than the estimated number of grains of sand on Earth (7.5 × 10¹⁸) multiplied by itself twice. This astronomical space is what makes coordination-free generation practical.

The Birthday Paradox and Collision Probability

P(collision) ≈ 1 - e^{-n²/2×2¹²²}

The birthday paradox tells us collisions become likely sooner than intuition suggests. For UUIDv4 with 122 random bits, you would need to generate approximately 2.71 × 10¹⁸UUIDs (2.71 quintillion) before reaching a 50% collision probability. To put this in perspective: generating 1 billion UUIDs per second would take 86 years to reach that threshold. In practice, most systems generate millions of UUIDs total over their lifetime — collision risk is effectively zero.

UUID Versions: v1, v4, v7, and Beyond

v1combines a timestamp and MAC address — sortable but leaks hardware identity. v4 is purely random and the most widely used (this tool generates v4). v5 hashes a namespace + name with SHA-1, producing deterministic UUIDs for the same input. v7 (RFC 9562, 2024) embeds a Unix millisecond timestamp in the first 48 bits, making UUIDs naturally time-sorted while keeping 74 random bits. v7 is quickly becoming the recommended choice for database primary keys because it combines uniqueness with B-tree-friendly ordering.

Database Performance Implications

Random UUIDv4 values cause B-tree index fragmentation in relational databases. Each new insert lands at a random position in the index, forcing page splits and increasing I/O. Benchmarks show UUIDv4 primary keys can be 2-5x slower than auto-increment integers for write-heavy workloads on PostgreSQL and MySQL. Solutions include: using UUIDv7 for time-sorted ordering, storing UUIDs as 16-byte binary instead of 36-character strings (saving 55% storage), or using a “hybrid” approach with internal sequential IDs and external-facing UUIDs.

Frequently Asked Questions

How does crypto.randomUUID() generate random values?

This tool uses the browser's native crypto.randomUUID() API, which draws from the operating system's cryptographically secure random number generator (CSPRNG). On Linux this is /dev/urandom, on macOS it is SecRandomCopyBytes, and on Windows it is BCryptGenRandom. These sources use hardware entropy (CPU timing jitter, interrupt timing) to ensure true randomness — far superior to Math.random().

What is the Nil UUID and when should I use it?

The Nil UUID (00000000-0000-0000-0000-000000000000) is the all-zeros UUID defined in RFC 4122. It serves as a sentinel value meaning “no identifier” or “uninitialized.” Use it as a default value in data structures, a placeholder in templates, or a representation of “null” in systems that require a valid UUID format. Never use it as an actual identifier for a real entity.

Should I use UUIDs or ULIDs for my project?

ULIDs (Universally Unique Lexicographically Sortable Identifiers) encode a 48-bit timestamp + 80 random bits as a 26-character Crockford Base32 string. They are time-sortable like UUIDv7 but shorter (26 vs. 36 characters). Choose UUIDs when you need broad ecosystem compatibility (every database, language, and ORM supports them). Choose ULIDs when string length matters and you control the full stack.