UUID v4 Generator
Generate cryptographically random UUID v4 values instantly. Uses the browser's native crypto.randomUUID() API - no data ever leaves your device.
What is UUID v4?
UUID v4 is the most widely used UUID version. It consists of 122 bits of cryptographically random data, with 4 bits fixed to indicate version 4 and 2 bits fixed to indicate the RFC 4122 variant. The result is a string like 550e8400-e29b-41d4-a716-446655440000 that is effectively guaranteed to be unique across all machines, all time, and all applications.
The probability of generating two identical v4 UUIDs is approximately 1 in 2122 - a number so large that generating a billion UUIDs per second for a trillion years would still leave the collision probability below 1 in 1018. In practice, UUID v4 collisions are simply not a concern.
How UUID v4 is Generated
This tool uses the browser's built-in crypto.randomUUID() method, which is specified in the Web Cryptography API. It reads from the operating system's cryptographically secure pseudorandom number generator (CSPRNG) - the same entropy source used for TLS key generation and password hashing.
- 128 random bits are generated by the CSPRNG.
- Bits 48-51 (the version field) are overwritten with
0100(version 4). - Bits 64-65 (the variant field) are overwritten with
10(RFC 4122 variant). - The 128 bits are formatted as 32 hex digits in the canonical
8-4-4-4-12pattern.
Common Use Cases
Database Primary Keys
UUID v4 is widely used as a primary key type in PostgreSQL (uuid column type), MySQL (CHAR(36) or BINARY(16)), and MongoDB. The random distribution can cause B-tree page fragmentation at scale - consider v7 for write-heavy tables.
Session & API Tokens
UUID v4 provides sufficient entropy for session identifiers, API keys, and CSRF tokens - as long as the UUID is stored and compared as a whole (never truncated). For security tokens, treat the full 122-bit UUID as opaque; do not embed secrets in predictable portions.
File Naming
When storing user uploads in object storage (S3, GCS, Azure Blob), using UUID v4 as the filename prevents collisions, prevents enumeration of file names, and avoids filesystem conflicts from files with the same original name uploaded by different users.
Distributed Systems
In microservice architectures, UUID v4 allows each service to generate IDs independently without a central sequence generator. Useful for correlation IDs in distributed traces, saga step identifiers, and idempotency keys in event-driven systems.
UUID v4 vs. Other Unique ID Schemes
| Scheme | Sortable | Size | Best for |
|---|---|---|---|
| UUID v4 | No | 128-bit | General-purpose, session tokens, file IDs |
| UUID v7 | Yes (ms) | 128-bit | Database PKs, time-ordered event streams |
| ULID | Yes (ms) | 128-bit | Base32-encoded sortable IDs |
| Snowflake | Yes (ms) | 64-bit | High-throughput distributed systems (Twitter) |
| Auto-increment | Yes | 32/64-bit | Single-database, non-distributed |
Storing UUIDs Efficiently
The canonical UUID string representation uses 36 characters (32 hex digits + 4 hyphens), requiring 36 bytes as ASCII or UTF-8. Storing UUIDs as strings is the most readable option but not the most compact.
BINARY(16)
The raw 16-byte binary representation. MySQL's BINARY(16) stores a UUID using 16 bytes versus 36, saving 56% space and improving index performance.
PostgreSQL uuid type
PostgreSQL's native uuid type stores UUIDs as 16 bytes internally regardless of how they are input. The type accepts and outputs canonical string form.
Base64 / Base64url
Base64-encoding the 16 bytes yields 22 characters (URL-safe, no padding). Useful when UUIDs appear in URLs, JWT claims, or JSON payloads where compact text representation matters.