UUID v4 Generator

What Is UUID v4?

UUID Version 4 is a cryptographically random 128-bit identifier defined in RFC 4122. Of its 128 bits, 122 are randomly generated — the remaining 6 bits are fixed to encode the version (0100) and variant (10). The result is a string like 550e8400-e29b-41d4-a716-446655440000, where the 4 in the third group identifies the version.

UUID v4 is the most widely used UUID version in the world. It is the default choice for user IDs, session tokens, API keys, file names, and resource identifiers in virtually every modern web application, cloud platform, and distributed system.

The Mathematics of UUID v4 Uniqueness

With 122 random bits, the total number of possible UUID v4 values is 2¹²² ≈ 5.3 × 10³⁶. To put this in perspective:

• →To have a 50% chance of a single collision, you would need to generate approximately 2.3 × 10¹⁸ UUIDs (2.3 quintillion).
• →If every person on Earth generated 1 billion UUIDs per second, it would take over 85 years to reach a 50% collision probability.
• →For any application generating fewer than 1 trillion UUIDs total, the collision probability is less than 1 in 10²⁴ — effectively zero.

This "probabilistic uniqueness" is what makes UUID v4 so powerful. You can generate IDs on any machine, in any process, at any time, without any coordination — and trust that they will never collide.

How We Generate UUID v4: The Web Crypto API

Our generator uses window.crypto.getRandomValues() — the browser's built-in Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). This is the same entropy source used by TLS, HTTPS, and browser-based cryptography. It is fundamentally different from Math.random(), which is a deterministic PRNG unsuitable for security-sensitive applications.

All generation happens entirely in your browser. No data is transmitted to our servers. No UUIDs are logged or stored. The generation is instantaneous — even bulk generation of 1,000 UUIDs completes in under a millisecond on modern hardware.

Common Use Cases for UUID v4

User and Account Identifiers

UUID v4 is the standard for user IDs in modern applications. Unlike sequential integers, a UUID v4 user ID cannot be guessed or enumerated. A malicious actor who knows their own user ID (550e8400-...) cannot derive another user's ID by incrementing a number. This prevents IDOR (Insecure Direct Object Reference) attacks at the identifier level.

Session Tokens and API Keys

Session tokens and API keys must be unpredictable. UUID v4's 122 bits of entropy make brute-force guessing computationally infeasible. While dedicated token formats (like JWT or opaque tokens) are often preferred for sessions, UUID v4 is a solid baseline for simple API key generation.

File and Asset Naming

When storing user-uploaded files, using UUID v4 as the filename prevents collisions and makes filenames unpredictable (preventing direct URL guessing). A file stored as 550e8400-e29b-41d4-a716-446655440000.jpg is both unique and opaque.

Distributed System Event IDs

In event-driven architectures, each event needs a globally unique ID. UUID v4 can be generated by any service, on any machine, without coordination — making it ideal for Kafka message keys, event store entries, and distributed transaction IDs.

UUID v4 and Database Performance

The main criticism of UUID v4 as a database primary key is index fragmentation. Because v4 is fully random, new records are inserted at random positions in the B-tree index rather than at the end. This causes frequent page splits, increased I/O, and degraded INSERT performance at scale (typically noticeable above ~10 million rows).

For tables under 10 million rows, this is rarely a practical concern. For larger tables, consider:

• →UUID v7 — time-ordered, eliminates fragmentation, RFC 9562 standard.
• →ULID — time-ordered, URL-safe, 26 characters.
• →MySQL's UUID_TO_BIN(uuid, 1) with swap flag — reorders v1 bytes for better index locality.

Storing UUID v4 in Databases

Always use the native binary storage format rather than a string column:

• →PostgreSQL: UUID — 16 bytes, native indexing, supports gen_random_uuid()
• →MySQL 8+: BINARY(16) with UUID_TO_BIN() / BIN_TO_UUID()
• →SQL Server: UNIQUEIDENTIFIER — 16 bytes
• →SQLite: TEXT (no native type) or BLOB for 16-byte storage

Using VARCHAR(36) wastes 20 bytes per row compared to binary storage and results in slower index operations due to string comparison overhead.

UUID v4 in Popular Frameworks

Most modern frameworks have first-class UUID v4 support:

• →Laravel (PHP): Str::uuid() or $table->uuid('id') in migrations
• →Django (Python): models.UUIDField(default=uuid.uuid4)
• →Spring Boot (Java): @GeneratedValue with GenerationType.UUID (JPA 3.1+)
• →Rails (Ruby): enable_extension 'pgcrypto' + id: :uuid
• →NestJS / TypeORM: @PrimaryGeneratedColumn('uuid')