UUID Generator

A UUID (Universally Unique Identifier) is a 128-bit number used to uniquely identify information in computer systems. Defined by RFC 4122, UUIDs are formatted as 32 hexadecimal digits displayed in five groups separated by dashes, following the pattern 8-4-4-4-12 (for example, 550e8400-e29b-41d4-a716-446655440000). The total number of possible UUID values is approximately 3.4 x 10^38, which makes them practically unique without requiring a central registration authority. UUIDs are used extensively as database primary keys, distributed system identifiers, session tokens, message correlation IDs, file names, and anywhere a globally unique reference is needed. Unlike auto-incrementing integers, UUIDs can be generated independently on any machine without coordination, making them ideal for distributed architectures, microservices, and offline-capable applications.

UUID version 1 is based on a combination of the current timestamp (measured in 100-nanosecond intervals since October 15, 1582) and the MAC address of the generating machine. This produces time-ordered identifiers that can be sorted chronologically, but it also means that the generating host and the approximate creation time can be inferred from the UUID itself. UUID version 4 is generated entirely from random or pseudo-random numbers, specifically using 122 bits of randomness. It does not contain any information about the host or the time of creation, which makes it the preferred choice for most modern applications where privacy and simplicity matter more than time ordering. Version 4 is by far the most commonly used variant in web development, APIs, and database systems. Our v1-like generator uses a real timestamp for the time component but substitutes a random node identifier instead of an actual MAC address, giving you the time-ordering benefits of v1 without exposing your hardware identity.

UUID v4 contains 122 bits of randomness (6 bits are reserved for the version and variant fields), which yields approximately 5.3 x 10^36 unique values. According to the birthday paradox, you would need to generate roughly 2.71 x 10^18 (2.71 quintillion) UUIDs before reaching a 50% probability of at least one collision. To put this in perspective, if you generated one billion UUIDs every second, it would take approximately 86 years to reach that threshold. In any practical application, the chance of a collision is effectively zero. Even the largest databases in the world with billions of records have an astronomically low probability of encountering a duplicate UUID v4. This extreme uniqueness, combined with cryptographically strong random number generation, is what makes UUID v4 the industry standard for generating identifiers without centralized coordination.

Yes. This tool uses the Web Crypto API (crypto.getRandomValues()) for all random number generation. The Web Crypto API draws entropy from the operating system's cryptographically secure pseudorandom number generator (CSPRNG), which is the same source used for TLS key generation and other security-critical operations. Unlike Math.random(), which uses a deterministic algorithm that can potentially be predicted, crypto.getRandomValues() produces output that is computationally infeasible to predict. Additionally, all UUID generation runs entirely in your browser. No data is transmitted to any server, no identifiers are logged, and nothing is stored remotely. You can verify this by inspecting network activity in your browser's developer tools while using the generator. The generated UUIDs are suitable for use as authentication tokens, session identifiers, API keys, and any other security-sensitive purpose.

The standard format with dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) is the canonical representation specified by RFC 4122 and is the most widely accepted format across programming languages, databases, and APIs. It is recommended as your default choice. The no-dashes format is useful when you need compact storage, such as in database columns with character limits, or when embedding UUIDs in URLs where dashes might cause issues. The uppercase format is sometimes required by legacy systems, Microsoft COM interfaces, and certain enterprise APIs that expect uppercase hexadecimal characters. The braces format ({uuid}) is the standard representation in Microsoft technologies including COM, .NET, and the Windows Registry. The URN format (urn:uuid:...) is the formal namespace representation defined in RFC 4122 itself, used in XML documents, SOAP messages, and formal identifier schemes where a fully qualified resource name is required.

The Nil UUID is the special UUID value where all 128 bits are set to zero: 00000000-0000-0000-0000-000000000000. It is defined in RFC 4122 as a valid UUID that represents an empty or non-existent identifier. Developers commonly use the Nil UUID as a default value, a placeholder for optional UUID fields, or a sentinel value indicating that no real identifier has been assigned yet. For example, a database record might use the Nil UUID in a foreign key column to indicate that the relationship has not been established. It is preferable to using NULL in some contexts because it maintains the UUID data type while clearly signaling the absence of a meaningful value. The Nil UUID is the only UUID where the version and variant bits do not follow the standard patterns, since every bit is zero.

Yes, UUIDs are widely used as database primary keys, especially in distributed systems where multiple nodes need to generate unique identifiers independently. UUID v4 provides excellent uniqueness guarantees without requiring a central sequence generator. However, there are trade-offs to consider. UUIDs are 128 bits (16 bytes) compared to a typical 32-bit or 64-bit auto-incrementing integer, which means they consume more storage space and can result in larger indexes. Random UUID v4 values also cause B-tree index fragmentation in some database engines because inserts are not sequential. For databases like PostgreSQL, which has a native UUID type, the storage overhead is minimal and performance is excellent. If sequential ordering matters for insert performance, consider using a v1-like (timestamp-based) UUID or alternatives like ULID that combine timestamps with randomness for naturally sorted identifiers. Always benchmark with your specific database engine and workload to make the right choice for your use case.