UUID Generator
Generate v4, v7, and nil UUIDs. Bulk generation and validation.
Click "Generate" to create UUIDs...
UUID Versions Explained
The UUID standard (RFC 9562, updated in 2024) defines several versions, each with different generation strategies:
| Version | Source | Sortable | Use Case |
|---|---|---|---|
| v1 | Timestamp + MAC address | Yes (by time) | Legacy systems, distributed databases |
| v4 | 122 random bits | No | General purpose, security tokens |
| v5 | SHA-1 hash of namespace + name | No | Deterministic IDs from known inputs |
| v7 | Timestamp + 74 random bits | Yes (by time) | Database primary keys, event IDs |
v4 is the most widely used version today. v7 is the recommended choice for new projects that need database-friendly, time-sortable identifiers.
Collision Probability: The Birthday Paradox
UUID v4 uses 122 random bits, giving 5.3 × 10³6 possible values. Using the birthday paradox formula, the probability of at least one collision after generating n UUIDs is approximately:
P(collision) ≈ 1 - e^(-n² / 2¹23)
For practical purposes: generating 1 billion UUIDs per second, it would take approximately 85 years to reach a 50% probability of a single collision. For most applications, UUID collisions are a non-concern.
UUIDs vs Auto-Increment IDs for Databases
The choice between UUIDs and auto-increment IDs involves trade-offs:
- Distributed generation: UUIDs can be generated on any node without coordination. Auto-increment requires a single source of truth or complex sharding schemes.
- Security: Auto-increment IDs leak information (total count, creation order, rate). UUIDs (especially v4) are non-guessable.
- Storage: UUIDs are 16 bytes vs 4-8 bytes for integers. This compounds with indexes and foreign keys.
- Index performance: Random v4 UUIDs cause B-tree index fragmentation. UUID v7 solves this by being time-ordered, resulting in sequential inserts similar to auto-increment.
When to Use Which Version
- UUID v4: Security tokens, API keys, session identifiers, or anywhere unpredictability matters more than sortability.
- UUID v7: Database primary keys, event sourcing, log entries, or anywhere time-ordering and uniqueness are both needed.
- Nil UUID: Default/placeholder values, "no value" sentinels in systems that require UUID-typed fields.
Frequently Asked Questions
What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 9562 (formerly RFC 4122). It is represented as 32 hexadecimal digits in five groups separated by hyphens: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. UUIDs are designed to be globally unique without requiring a central authority.
What is the difference between UUID v4 and v7?
UUID v4 is entirely random (122 random bits), making it unpredictable and ideal for security-sensitive identifiers. UUID v7 embeds a Unix timestamp in the first 48 bits, making it time-sortable while retaining 74 random bits. v7 is preferred for database primary keys because it preserves insertion order and improves index performance.
What is the probability of a UUID collision?
For UUID v4, the probability of a collision after generating n UUIDs is approximately n²/2¹23. You would need to generate 2.71 × 10¹8 UUIDs (2.71 quintillion) to have a 50% chance of a single collision. At 1 billion UUIDs per second, this would take over 85 years.
Should I use UUIDs or auto-increment IDs for my database?
UUIDs are better for distributed systems (no coordination needed), security (IDs are not guessable), and merging datasets. Auto-increment IDs are better for storage efficiency (4-8 bytes vs 16), index performance (sequential inserts), and human readability. UUID v7 offers a middle ground: globally unique but time-sortable for better index performance.
What is a nil UUID?
A nil UUID is all zeros: 00000000-0000-0000-0000-000000000000. It is defined in RFC 9562 and is commonly used as a sentinel value or default/placeholder where a UUID is expected but no meaningful value exists. It should never be used as an actual identifier.
How does UUID validation work?
This tool validates UUIDs by checking: correct format (8-4-4-4-12 hex digits), valid version nibble (position 13 must be 1-7), and valid variant bits (position 17 must be 8, 9, a, or b for RFC 9562 variant). The nil UUID is also recognized as valid.