What are the differences between UUID versions (v1, v4, v5)?

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.

Are UUIDs truly unique? Can collisions happen?

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.

Should I use UUIDs or auto-incrementing integers as database primary keys?

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.

How do I store UUIDs efficiently in databases?

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.

Can I generate UUIDs in different programming languages?

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.

What is the difference between UUID and GUID?

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.

When should I use UUID v5 for deterministic ID generation?

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.

Home/Tools/Developer/UUID/GUID Generator

UUID/GUID Generator

Generate universally unique identifiers (UUIDs/GUIDs) in multiple versions (v1, v4, v5). Bulk generation, validation, and format conversion.

100% Private - Runs Entirely in Your Browser

No data is sent to any server. All processing happens locally on your device.

Loading UUID/GUID Generator...

UUID Version

Quantity

Format

Namespace (v5 only)

Name (v5 only)

UUID to Parse

Loading interactive tool...

JavaScript Required

This interactive tool requires JavaScript to function. Please enable JavaScript in your browser to use the full features.

The tool description and documentation above provide information about this tool's capabilities. For the best experience, please enable JavaScript and refresh the page.

Building Distributed Systems?

From UUIDs to microservices, our team builds scalable, distributed applications.

Learn About Software Development Get Free Consultation

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.

ℹ️ 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.