Want to learn more?
Understand the differences between UUID versions and choose the right one for your application.
Read the guideBuilding Distributed Systems?
From UUIDs to microservices, our team builds scalable, distributed applications.
What Is a UUID Generator
A UUID (Universally Unique Identifier) generator creates 128-bit identifiers that are guaranteed to be unique across space and time without requiring a central registration authority. UUIDs are formatted as 32 hexadecimal characters displayed in five groups separated by hyphens: 550e8400-e29b-41d4-a716-446655440000. They are fundamental to distributed systems, databases, and APIs where globally unique identifiers are needed without coordination between systems.
UUIDs solve a critical problem in distributed computing: how do independent systems create identifiers that will never collide? Auto-incrementing database IDs work within a single database but fail when merging data from multiple sources, synchronizing offline clients, or building microservices architectures. UUIDs eliminate this problem entirely.
How UUIDs Work
The UUID specification (RFC 9562, formerly RFC 4122) defines several versions, each generating uniqueness through different mechanisms:
| Version | Name | Generation Method | Use Case |
|---|---|---|---|
| v1 | Time-based | Timestamp + MAC address | Legacy systems needing temporal ordering |
| v3 | Name-based (MD5) | MD5 hash of namespace + name | Deterministic IDs from known inputs |
| v4 | Random | 122 bits of random data | General-purpose unique identifiers |
| v5 | Name-based (SHA-1) | SHA-1 hash of namespace + name | Deterministic IDs (preferred over v3) |
| v7 | Time-ordered | Unix timestamp + random data | Sortable IDs for databases (newest) |
UUID v4 is the most commonly used version. With 122 random bits, the probability of generating two identical UUIDs is astronomically low—you would need to generate 2.71 × 10^18 UUIDs before having a 50% chance of a single collision.
UUID v7 (introduced in RFC 9562) is gaining adoption because it embeds a Unix millisecond timestamp in the first 48 bits, making UUIDs naturally sortable by creation time. This significantly improves database index performance compared to random v4 UUIDs.
Common Use Cases
- Database primary keys: Use UUIDs instead of auto-incrementing integers for globally unique, merge-safe identifiers
- API resource identifiers: Expose UUIDs in URLs and responses to avoid leaking sequential information
- Distributed systems: Generate IDs independently on multiple servers without coordination or collision risk
- Session tokens: Create unique session identifiers for authentication systems
- File naming: Generate unique filenames for uploads to prevent collisions in object storage
Best Practices
- Use v7 for new database applications — Time-ordered UUIDs produce better B-tree index performance than random v4 UUIDs
- Use v4 when ordering doesn't matter — Random UUIDs are the simplest choice when temporal sorting is unnecessary
- Use v5 for deterministic generation — When you need the same input to always produce the same UUID (namespace mapping)
- Never use UUIDs as security tokens — v1 UUIDs leak timestamps and MAC addresses; even v4 UUIDs are not cryptographically secure
- Consider storage format — Store as BINARY(16) in databases for efficiency rather than CHAR(36); this halves storage and improves query performance
References & Citations
- P. Leach, M. Mealling, R. Salz. (2005). RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace. Internet Engineering Task Force. Retrieved from https://www.rfc-editor.org/rfc/rfc4122 (accessed January 2025)
- K. Davis et al.. (2024). UUID Version 7 Draft Specification. Internet Engineering Task Force. Retrieved from https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format (accessed January 2025)
- Wolfram MathWorld. (2024). Probability of UUID Collisions. Retrieved from https://mathworld.wolfram.com/BirthdayProblem.html (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Frequently Asked Questions
Common questions about the UUID/GUID Generator
A UUID (Universally Unique Identifier) is a 128-bit number guaranteed to be unique across space and time without coordination. Format: 8-4-4-4-12 hexadecimal digits (e.g., 550e8400-e29b-41d4-a716-446655440000). Why use UUIDs: (1) Globally unique - No central registry needed, generate anywhere without conflicts. (2) Distributed systems - Multiple systems can generate IDs independently. (3) Merge-safe - Combining databases never creates ID collisions. (4) Security - Non-sequential prevents enumeration attacks. (5) Migration-friendly - Move records between systems without ID conflicts. Use cases: Database primary keys, Microservices communication, File naming, Session IDs, API request IDs, Document identifiers. Alternative: Auto-incrementing integers are simpler but: Reveal record counts, Cause merge conflicts, Enable enumeration attacks, Require coordination. Use UUIDs when: Working with distributed systems, Need globally unique IDs, Merging databases, Building APIs, Prioritizing security.
UUID has multiple versions for different use cases: UUIDv1 (Time-based) - Includes timestamp and MAC address, Sortable chronologically, Reveals creation time and computer MAC, Privacy concern - MAC address is identifiable, Use when: Need chronological sorting, Privacy not a concern. UUIDv4 (Random) - Purely random (122 bits of randomness), No embedded information, Most popular version, Collision probability: 1 in 5.3 × 10^36 for one billion UUIDs per second for 100 years, Use when: Need maximum randomness, Privacy important, No sorting required. UUIDv5 (Name-based SHA-1) - Generated from namespace + name using SHA-1 hash, Deterministic - same input always produces same UUID, Reproducible without storage, Use when: Need reproducible IDs, Deriving UUIDs from existing identifiers, Content-addressable systems. Deprecated: UUIDv2 (DCE Security) - rarely used, UUIDv3 (Name-based MD5) - obsolete, use v5 instead. Recommendation: Use v4 for general purposes, v1 when you need time sorting, v5 when you need deterministic generation.
UUIDs are designed to be unique with astronomically low collision probability: UUIDv4 Collision Math: 122 random bits = 2^122 possible values (5.3 × 10^36), Probability of collision with 1 billion UUIDs per second for 100 years: ~0.0000000001%, Need to generate 2^61 UUIDs to have 50% collision chance, Effectively impossible in practice. However, collisions CAN happen if: Using broken random number generators (Mersenne Twister, poor seeding), Generating millions of UUIDs in tight loops with weak RNG, Virtualization/containerization cloning with same RNG state, Bugs in UUID library implementations. UUIDv1 uniqueness depends on: MAC address uniqueness (generally guaranteed), Clock accuracy and monotonicity, More predictable but still effectively unique. Best practices: Use cryptographically secure random number generators (not Math.random()), Don't implement UUID generation yourself - use tested libraries, Test UUID uniqueness in your application, Consider UUIDv7 (time-ordered) for databases requiring sortability. In practice, if using proper libraries, collisions are not a real concern.
The UUID vs auto-increment debate has important trade-offs: UUIDs as Primary Keys - Pros: Globally unique (merge databases safely), Generate client-side (reduce database roundtrips), Distributed-friendly (multiple services generate IDs), Secure (can't enumerate records), Partition-friendly (distribute across shards). UUIDs as Primary Keys - Cons: Larger storage (16 bytes vs 4-8 bytes for integers), Slower lookups and joins (larger indexes), Random insertion causes index fragmentation (performance hit), Harder to debug (complex values), URL-unfriendly (long identifiers). Auto-Increment Integers - Pros: Small storage (4-8 bytes), Fast lookups and joins (compact indexes), Sequential insertion (better performance), Human-readable, URL-friendly. Auto-Increment Integers - Cons: Database-dependent (hard to merge), Reveal record counts (security/competitive issue), Enumeration attacks (guess valid IDs), Distributed systems problems (coordination needed). Modern solution: UUIDv7 (coming) - Time-ordered UUIDs combining benefits of both. Recommendation: Use auto-increment for: Single database systems, Internal applications, Performance-critical apps. Use UUIDs for: Microservices, APIs, Multi-tenant SaaS, Distributed systems, Security-sensitive apps.
UUID storage varies by database with significant performance implications: PostgreSQL: Native UUID type (16 bytes), use uuid column type, Supports indexes, Very efficient. MySQL 8.0+: Native UUID type, use UUID or BINARY(16), Convert string to binary: UUID_TO_BIN(), Convert back: BIN_TO_UUID(). MySQL 5.7 and earlier: Store as CHAR(36) (wasteful - 36 bytes), Better: Store as BINARY(16), Manual conversion: UNHEX(REPLACE(uuid, '-', '')). SQL Server: Native uniqueidentifier type (16 bytes), Supports indexes, Use NEWSEQUENTIALID() for better performance (reduces fragmentation). MongoDB: Native UUID/GUID support, store as BinData type. Performance Tips: (1) Always store as binary (16 bytes), never as string (36 bytes). (2) Use indexed UUID columns sparingly. (3) Consider UUIDv1 or UUIDv7 for time-ordering (reduces index fragmentation). (4) Partition by UUID prefix if needed. (5) Use covering indexes for UUID lookup queries. Storage comparison: UUID as CHAR(36): 36 bytes, UUID as BINARY(16): 16 bytes (56% savings), Integer as INT: 4 bytes, Integer as BIGINT: 8 bytes. For high-volume systems, the storage difference matters significantly.
UUID generation is built into most languages: JavaScript/Node.js: crypto.randomUUID() (Node 14.17+, browser), require('uuid').v4() (npm package). Python: import uuid, uuid.uuid4() (random), uuid.uuid1() (time-based), uuid.uuid5() (name-based). Java: java.util.UUID, UUID.randomUUID() (v4), UUID.nameUUIDFromBytes() (v3/v5). C#/.NET: System.Guid, Guid.NewGuid() (v4). PHP: uniqid() (not true UUID), Ramsey\\Uuid\\Uuid::uuid4() (proper library). Ruby: require 'securerandom', SecureRandom.uuid. Go: github.com/google/uuid, uuid.New() or uuid.NewRandom(). Rust: use uuid::Uuid, Uuid::new_v4(). SQL: PostgreSQL: gen_random_uuid(), MySQL: UUID(), SQL Server: NEWID(). Key principles: Use built-in crypto-secure functions, Don't implement your own, Avoid Math.random() or similar weak RNGs, Test for uniqueness in critical applications. Most languages have battle-tested UUID libraries - never roll your own.
UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) are the same thing with minor differences in terminology and presentation: UUID - Standard term (RFC 4122), Used in most technologies and languages, Written with lowercase hex digits (550e8400-e29b-41d4-a716-446655440000), Common in open-source, Linux/Unix, APIs. GUID - Microsoft's term for the same concept, Used primarily in Windows and .NET ecosystem, Often written with uppercase hex digits (550E8400-E29B-41D4-A716-446655440000), Sometimes shown in Windows registry format with braces: {550E8400-E29B-41D4-A716-446655440000}. Technical equivalence: Both are 128-bit identifiers, Same format: 8-4-4-4-12 hex digits, Same generation algorithms, Same uniqueness guarantees, Fully interoperable. Practical differences: Case sensitivity (lowercase vs uppercase is convention, not requirement), Brace formatting (cosmetic), API/function naming (UUID.randomUUID() vs Guid.NewGuid()). Recommendation: Use "UUID" for cross-platform systems, Use "GUID" when working specifically with Microsoft technologies, Convert between formats as needed (trivial - just case and braces), Don't worry about the distinction - they're the same thing.
UUIDv5 is ideal when you need reproducible IDs from existing data: How UUIDv5 works: Takes namespace UUID + name string, Applies SHA-1 hash, Produces deterministic UUID (same input → same output), Version bits set to 5. Use cases: (1) Content-addressed storage - File SHA-256 hash → UUID for referencing. (2) Idempotent API operations - Request parameters → UUID ensures same request gets same ID. (3) Derived identifiers - User email → UUID without storing mapping. (4) Data migration - Old ID → UUID for backward compatibility. (5) Reproducible test data - Generate consistent UUIDs across test runs. Standard namespaces: DNS: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 (domain names), URL: 6ba7b811-9dad-11d1-80b4-00c04fd430c8 (URLs), OID: 6ba7b812-9dad-11d1-80b4-00c04fd430c8 (ISO OIDs), X500: 6ba7b814-9dad-11d1-80b4-00c04fd430c8 (X.500 DNs). Example: uuid5(DNS_NAMESPACE, "example.com") → Always produces same UUID. Don't use v5 for: Primary security identifiers (not random), Session tokens (predictable), One-time codes (not random enough). Recommendation: Use v5 when repeatability matters, v4 when randomness required.
ℹ️ Disclaimer
This tool is provided for informational and educational purposes only. All processing happens entirely in your browser - no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results. Use at your own discretion.