Universally Unique Identifiers (UUIDs) are 128-bit values used to identify resources without requiring a central authority, making them essential for distributed systems, databases, APIs, and microservice architectures. The standard format — 8-4-4-4-12 hexadecimal characters like 550e8400-e29b-41d4-a716-446655440000 — provides 2^122 possible values (5.3 × 10^36), making accidental collisions effectively impossible. Our UUID generator creates version 4 (random) UUIDs instantly, with options to generate multiple UUIDs at once, copy to clipboard, and format as uppercase or lowercase. UUID v4 is the most common version in modern software, used by PostgreSQL's gen_random_uuid(), Python's uuid4(), JavaScript's crypto.randomUUID(), and most ORMs. Whether you need a unique identifier for a database record, API key, session token, or test fixture, this tool provides cryptographically random UUIDs that meet RFC 4122 specifications.
UUID versions and when to use each
UUID v1 combines a timestamp with the machine's MAC address — guaranteed unique but reveals creation time and hardware identity, creating privacy concerns. UUID v3 and v5 are deterministic hashes: v3 uses MD5, v5 uses SHA-1. Given the same namespace and name, they always produce the same UUID — useful for generating consistent identifiers from natural keys (e.g., converting email addresses to user IDs). UUID v4 uses 122 bits of random data, providing the strongest uniqueness guarantee without leaking any information. UUID v7 (RFC 9562, 2024) embeds a Unix timestamp in the first 48 bits while keeping 74 random bits — sortable by creation time, making it ideal for database primary keys where index performance matters. For most applications, v4 is the default choice; switch to v7 for database primary keys where insertion order matters.
UUID collision probability in practice
UUID v4 uses 122 random bits, yielding 5.3 × 10^36 possible values. The birthday problem determines collision probability: after generating 2.7 × 10^18 (2.7 quintillion) UUIDs, there is a 50% chance of one collision. In practical terms, generating 1 billion UUIDs per second for 85 years reaches this threshold. At more realistic scales — a system generating 1 million UUIDs per day — the probability of any collision in 100 years is approximately 1 in 10^24. This assumes a proper random number generator (CSPRNG); using Math.random() in JavaScript (which is not cryptographically secure) reduces entropy and increases collision risk. Always use crypto.randomUUID(), uuid v4 libraries, or database-native UUID functions for production systems.
UUIDs as database primary keys: tradeoffs
UUIDs as primary keys enable decentralized ID generation (applications create IDs without database roundtrips) and prevent enumeration attacks (users cannot guess other records' IDs). However, random UUID v4 values hurt B-tree index performance — random insertions cause page splits and fragmentation, increasing write amplification by 2-5x compared to sequential integer keys. UUID v7 solves this with timestamp-prefixed randomness, providing both uniqueness and sequential ordering. Storage cost is also higher: 16 bytes versus 4-8 bytes for integers, significant in tables with billions of rows and multiple indexes. A common pattern combines UUIDs as public-facing identifiers with integer auto-increment keys internally, joining tables on the efficient integer while exposing only the secure UUID to APIs and URLs.