UUID & GUID Generator & Inspector
Generate cryptographically secure v4 (Random) and modern v7 (Time-Ordered RFC 9562) UUIDs in single or bulk batches with custom formatting and validation.
1. The Evolution of Universally Unique Identifiers: v4 vs. v7 (RFC 9562)
A Universally Unique Identifier (UUID)—also designated as a Globally Unique Identifier (GUID) in Microsoft ecosystems—is a 128-bit identifier standardized to ensure uniqueness across distributed systems without requiring a central coordination authority.
For over two decades, Version 4 (v4) served as the dominant standard by generating 122 bits of pure pseudorandom entropy. However, random v4 UUIDs create significant performance issues in databases (MySQL, PostgreSQL, MongoDB): random primary keys cause heavy B-Tree index page fragmentation and random I/O thrashing on write-heavy tables.
In 2024, the IETF ratified RFC 9562, introducing Version 7 (v7). UUID v7 combines an ordered 48-bit Unix epoch millisecond timestamp with 74 bits of cryptographic entropy. This enables time-ordered sequential indexing like auto-incrementing IDs while retaining global uniqueness and preventing enumeration attacks.
2. UUID Specification & RFC Standards Matrix
| Specification | Generation Algorithm | Primary Engineering Use Case | Database Index Impact |
|---|---|---|---|
| Version 4 (v4) | 122 bits of CSPRNG randomness (RFC 4122) | Session tokens, transient identifiers, REST API nonces | High B-Tree index fragmentation |
| Version 7 (v7) | 48-bit Unix timestamp + 74 bits CSPRNG (RFC 9562) | Modern database primary keys, event streaming, log tracing | Sequential write-friendly; zero fragmentation |
| Nil UUID | All 128 bits set to zero (00000000-...) |
Null object references, default database states | Static reference |
3. The Mathematics of Version 4 Collision Resistance
Version 4 UUIDs allocate 6 bits to version and variant metadata, leaving 122 bits of pure cryptographic randomness ($2^{122} \approx 5.3 \times 10^{36}$ unique identifiers). To reach a 50% probability of a single collision (the Birthday Paradox), a system would need to generate approximately $2.3 \times 10^{18}$ UUIDs—the equivalent of generating 1 billion UUIDs every second for 73 consecutive years.
4. Client-Side Execution & Privacy Guarantee
All identifier generation, timestamp packing, and validation routines execute locally within your browser sandbox using the native Web Crypto API (crypto.randomUUID and crypto.getRandomValues). Generated keys, database seeds, and test fixtures are never transmitted across external networks or stored on remote servers.
5. Frequently Asked Questions
Why should I use UUID v7 instead of UUID v4 for database primary keys?
UUID v7 sorts chronologically because its first 48 bits encode a Unix millisecond timestamp. When inserted into relational databases (such as PostgreSQL or MySQL InnoDB), new records are appended to the end of the B-Tree index rather than inserted randomly, reducing disk I/O and boosting insert performance by up to 400%.
Is Math.random() safe for generating UUIDs?
No. Standard Math.random() is not cryptographically secure and produces predictable sequences that lead to collisions. This tool uses the native Web Crypto API (crypto.getRandomValues) to ensure genuine cryptographic entropy.
How does the UUID Inspector determine the version?
The 13th hexadecimal character of a canonical UUID identifies its specification version (e.g. ...-4xxx-... is v4, ...-7xxx-... is v7), and the 17th character identifies the RFC variant (typically 8, 9, a, or b).