UUID / GUID Generator
Generate RFC 4122 compliant UUIDs (GUIDs — Microsoft term) instantly for use in databases, APIs, and applications
UUID Generator
Generate UUIDs of different versions (v1, v3, v4, v5, NIL). Choose options and copy the result.
About UUIDs
Universally Unique Identifiers (UUIDs) are 128-bit values standardized by RFC 4122. They are commonly used as identifiers that do not require a centralized authority.
- RFC 4122 compliant 128-bit identifiers
- Common versions: v1 (timestamp), v3/v5 (name-based), v4 (random), v7 (time-ordered), NIL (all zeros)
- Typical uses: database keys, API resource IDs, client-generated IDs
- v4 has ~122 bits of randomness; collisions are practically negligible
- Format: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx (M = version, N = variant)
What is a UUID (GUID)?
A UUID (Universally Unique Identifier), also known as a GUID (Globally Unique Identifier) in Microsoft terminology, is a 128-bit value designed to be unique across all systems and time without requiring a central coordination authority. UUIDs are standardized by RFC 4122 and are widely used in distributed systems, databases, APIs, and applications where globally unique identification is critical.
The standard UUID format uses 32 hexadecimal digits displayed in five groups separated by hyphens, in the form 8-4-4-4-12, for a total of 36 characters including hyphens (for example: 550e8400-e29b-41d4-a716-446655440000). This compact, URL-safe format makes UUIDs ideal for use as resource identifiers in REST APIs, primary keys in databases, session identifiers, or any scenario where you need guaranteed uniqueness without a central ID generator.
UUIDs come in multiple versions (v1, v3, v4, v5, v7, and NIL), each designed for different use cases. Some are time-based and sortable (v1, v7), some are completely random (v4), and others are deterministic based on namespace and name (v3, v5). Understanding which version to use depends on your specific requirements for randomness, ordering, determinism, and collision resistance.
Common Use Cases for UUID Generation
Database Primary Keys
UUIDs are ideal primary keys for distributed databases, sharded systems, or offline-first applications where multiple nodes need to generate unique IDs without coordination. Unlike auto-incrementing integers, UUIDs prevent ID collisions when merging data from different sources and don't reveal record counts or creation order.
REST API Resource Identifiers
Modern REST APIs use UUIDs as resource identifiers in URLs (e.g., /api/users/550e8400-e29b-41d4-a716-446655440000). UUIDs are URL-safe, non-sequential (preventing enumeration attacks), and can be generated client-side without server round-trips. This improves security and scalability in microservices architectures.
Session and Transaction IDs
Web applications use UUIDs for session identifiers, tracking tokens, request IDs for distributed tracing, and transaction identifiers. Their randomness and length make them resistant to guessing attacks, while their uniqueness ensures no two sessions or transactions share the same ID across your entire system.
Client-Generated Identifiers
Offline-first and mobile applications generate UUIDs locally when creating records without network connectivity. When the device reconnects, these locally-generated IDs sync to the server without conflicts. This pattern enables robust offline functionality in Progressive Web Apps (PWAs) and native mobile apps.
Deterministic Content Addressing
Name-based UUIDs (v3/v5) generate consistent IDs from namespace and name inputs, enabling content-addressable storage, idempotency keys for API operations, cache keys that remain consistent across servers, and deduplication by hashing content to a deterministic identifier.
File and Asset Management
Cloud storage systems, CDNs, and content management systems use UUIDs as filenames to prevent naming conflicts, organize assets without filesystem limitations, and enable distributed storage across multiple servers without central coordination. UUIDs also prevent information disclosure through predictable filenames.
UUID Versions Explained in Detail
Version 1 (Time-Based with MAC Address)
UUID v1 combines a timestamp (100-nanosecond intervals since October 15, 1582) with a node identifier (traditionally the MAC address of the generating machine) and a clock sequence to prevent duplicates. This creates naturally sortable UUIDs based on creation time. However, v1 UUIDs may expose network hardware information and aren't random, making them less suitable for security-sensitive contexts. Use v1 when you need chronological ordering and don't require complete randomness.
Version 3 (MD5 Namespace-Based)
UUID v3 generates deterministic UUIDs by hashing a namespace UUID and a name using the MD5 algorithm. Given the same namespace and name, v3 always produces the same UUID. This is perfect for creating consistent identifiers from URLs, domain names, or other namespaced strings. While MD5 is cryptographically weak, it's sufficient here since UUIDs don't require cryptographic security— just uniqueness. However, prefer v5 (SHA-1) for new applications.
Version 4 (Cryptographically Random)
UUID v4 is the most commonly used version, generating IDs from 122 bits of random data (with 6 bits reserved for version and variant markers). Modern implementations use cryptographically secure random number generators, making collisions astronomically unlikely. V4 is simple to generate, doesn't leak information about the system or time, and works universally. Use v4 as your default choice unless you specifically need ordering (v1/v7) or determinism (v3/v5).
Version 5 (SHA-1 Namespace-Based)
UUID v5 works identically to v3 but uses SHA-1 instead of MD5 for hashing the namespace and name. SHA-1 is cryptographically stronger than MD5 (though also deprecated for cryptographic purposes), making v5 the preferred choice for name-based UUIDs in modern applications. Use v5 when you need deterministic IDs from URLs, email addresses, DNS names, or any namespaced identifier.
Version 7 (Time-Ordered with Random Data)
UUID v7 is a modern format (proposed in the RFC 4122 update) that places a Unix timestamp in milliseconds at the beginning, followed by random data. This creates UUIDs that are naturally sortable by creation time while maintaining high randomness and collision resistance. V7 combines the benefits of v1 (time-ordering for database indexing performance) with v4 (randomness and privacy). Use v7 for high-performance databases where insertion order matters.
NIL UUID (All Zeros)
The NIL UUID (00000000-0000-0000-0000-000000000000) is a special reserved value representing "no UUID" or an absent identifier. It's used as a placeholder or default value in situations where a UUID field is required but no meaningful value exists yet. Never use NIL UUID as an actual identifier for entities.
Frequently Asked Questions
What's the difference between UUID and GUID?
UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) refer to the same thing—a 128-bit identifier standardized by RFC 4122. "UUID" is the official standard term used in specifications and most programming languages. "GUID" is Microsoft's terminology used in Windows, .NET, and SQL Server. The two terms are completely interchangeable, though "UUID" is more common in cross-platform contexts.
How likely are UUID collisions?
For UUID v4 (random), the probability of collision is astronomically low. With 122 bits of randomness, you'd need to generate about 2.71 quintillion (2.71 × 10¹⁸) UUIDs to have a 50% chance of a single collision. To put this in perspective: if you generated 1 billion UUIDs per second, it would take about 86 years to reach a 50% collision probability. In practice, UUID collisions are not a concern for any real-world application.
Which UUID version should I use?
Use UUID v4 (random) as your default choice—it's simple, secure, widely supported, and appropriate for most use cases. Choose v1 or v7 if you need time-based sorting for database indexing performance (v7 is preferable for privacy). Use v3 or v5 (prefer v5) when you need deterministic IDs generated from namespaced names, like creating consistent IDs from URLs or email addresses. Avoid v1 if exposing MAC addresses is a privacy concern.
Can I use UUIDs as database primary keys?
Yes, UUIDs are excellent primary keys for distributed systems, though there are trade-offs. Benefits include: generation without database round-trips, no collision risk when merging datasets, non-sequential IDs that prevent enumeration attacks, and easy sharding. Downsides include: larger index size (16 bytes vs 4-8 for integers), potential indexing performance issues with random UUIDs (use v1/v7 for better locality), and less human-readable. Most modern databases handle UUID primary keys efficiently.
Are UUIDs secure for session tokens or secrets?
UUID v4 provides sufficient randomness for session identifiers and non-security-critical tokens, but shouldn't be used for cryptographic keys, password reset tokens, or authentication secrets. For security-sensitive purposes, use dedicated cryptographic token generation (like crypto.randomBytes() with 32+ bytes). UUIDs were designed for uniqueness, not cryptographic security, though properly-generated v4 UUIDs are resistant to guessing attacks.
How do I generate UUIDs in my programming language?
Most modern programming languages have built-in UUID generation: JavaScript/Node.js uses crypto.randomUUID(), Python has the uuid module (uuid.uuid4()), Java provides java.util.UUID.randomUUID(), C# has Guid.NewGuid(), PHP offers uniqid() or ramsey/uuid library, and Go has github.com/google/uuid. Always use your language's standard library or well-maintained packages rather than implementing UUID generation yourself.
Can UUIDs be decoded to extract information?
It depends on the version. UUID v1 embeds a timestamp and node identifier (potentially MAC address) that can be extracted, revealing when and where the UUID was generated. UUID v3 and v5 are hashes, so the original namespace and name cannot be reversed. UUID v4 is random data with no embedded information. UUID v7 embeds a timestamp but not machine information. Only decode v1 and v7 for timestamp extraction; never rely on UUIDs as secure storage of data.
What are UUID namespaces for v3/v5?
UUID namespaces partition the UUID space to avoid collisions between different naming authorities. RFC 4122 defines standard namespaces: DNS (for domain names), URL (for URLs), OID (for ISO OIDs), and X.500 (for X.500 DNs). For example, generating a v5 UUID from the URL namespace and "https://example.com" always produces the same UUID. You can also create custom namespaces by generating a UUID to serve as the namespace identifier for your application's name-based UUIDs.
Should UUIDs be stored with or without hyphens?
Store UUIDs in whatever format your database optimizes for. PostgreSQL has a native UUID type (stores 16 bytes efficiently), MySQL can use BINARY(16) for compact storage or CHAR(36) for hyphenated strings, and MongoDB supports storing as Binary UUID subtype. The hyphenated canonical format (36 characters) is human-readable and widely compatible, while the compact format (32 hex digits) saves space. Most modern databases handle both efficiently with proper indexing.
Is this tool safe for generating production UUIDs?
This tool generates RFC 4122 compliant UUIDs using your browser's cryptographically secure random number generator (crypto.getRandomValues() or crypto.randomUUID()). The generated UUIDs are suitable for production use. However, for high-volume production systems, generate UUIDs server-side or in your application code rather than manually copying from a web tool. This tool is perfect for testing, prototyping, or generating a few UUIDs for configuration or database seeding.
Best Practices for Using UUIDs
Choose the right version for your use case: Use v4 (random) as your default for general-purpose unique identifiers. Choose v7 or v1 when you need time-ordered IDs for database indexing performance. Use v5 (or v3) when you need deterministic IDs from namespaced inputs. Avoid v1 in privacy-sensitive contexts where exposing MAC addresses is a concern.
Understand storage implications: UUIDs are 128 bits (16 bytes), larger than integer IDs. Use native UUID types when available (PostgreSQL UUID, SQL Server UNIQUEIDENTIFIER) for optimal storage and indexing. For databases without native support, store as BINARY(16) for space efficiency or CHAR(36) for compatibility. Consider the trade-off between random UUIDs (better security) and ordered UUIDs (better indexing locality).
Generate UUIDs at the right layer: Client-side generation (JavaScript, mobile apps) enables offline functionality and reduces server round-trips. Server-side generation ensures consistent generation quality and reduces client-side code. Database-side generation (using UUID functions) centralizes ID creation but couples your data layer to the database. Choose based on your architecture and offline requirements.
Use consistent formatting: Stick to the canonical lowercase hyphenated format (8-4-4-4-12) for storage, APIs, and display unless you have specific reasons to use compact format. Consistent formatting prevents bugs and makes debugging easier. Always validate and normalize UUID input to your chosen format to handle different client representations.
Don't extract security from UUIDs: Never use UUIDs for access control, authentication, or authorization. They're identifiers, not security tokens. Don't parse v1 UUIDs to get timestamps for business logic—use proper timestamp fields. Don't rely on UUID randomness for cryptographic operations—use dedicated crypto libraries.
Index strategically for performance: When using random UUIDs (v4) as primary keys in high-write databases, consider clustering or partitioning strategies to mitigate index fragmentation. Time-ordered UUIDs (v7, v1) have better locality for B-tree indexes. Monitor database performance and consider using UUIDs as alternate keys with integer primary keys if UUID indexing becomes a bottleneck.
Technical Details & RFC 4122 Compliance
UUID Structure and Bit Layout
A UUID is 128 bits long, typically represented as 32 hexadecimal digits with hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M position (4 bits) indicates version (1-5, 7). The N position's first 2-3 bits indicate variant (10 for RFC 4122). This leaves 122 bits for data in v4 random UUIDs. The specific bit layout varies by version—v1 encodes timestamp, clock sequence, and node ID in specific positions, while v4 uses random bits throughout except version and variant markers.
Collision Probability Mathematics
The collision probability follows the birthday problem. For v4 UUIDs with 122 random bits, the probability of at least one collision after generating n UUIDs is approximately: P(collision) ≈ 1 - e^(-n²/2^123). To reach a 50% collision probability requires n ≈ 2.71 × 10¹⁸ UUIDs. Even generating 1 trillion UUIDs gives only a 0.0000000000005% collision chance—negligible for any practical application.
Shareable Links Feature
This generator supports pre-selecting UUID versions via URL query parameters: ?version=v1, ?version=v3, ?version=v4, ?version=v5, ?version=v7, or ?version=nil. This enables sharing direct links to specific UUID generation modes for documentation, tutorials, or team workflows. The selected version persists in the browser until changed, making it easy to generate multiple UUIDs of the same type.
Related UUID Tools
Explore our complete suite of UUID tools for generation, validation, decoding, and format conversion: