What is a UUID and what does it stand for?

UUID stands for Universally Unique Identifier. It is a 128-bit label used to uniquely identify information in computer systems without requiring a central coordinating authority. UUIDs are standardized by RFC 4122 and are represented as 32 hexadecimal digits displayed in five groups separated by hyphens, following the pattern 8-4-4-4-12 (e.g., 550e8400-e29b-41d4-a716-446655440000).

How unique is a UUID v4?

A UUID v4 has 122 random bits, producing approximately 5.3 undecillion (5.3 x 10^36) possible values. The probability of generating two identical UUIDs is astronomically low. You would need to generate about 2.71 quintillion UUIDs to have a 50% chance of a single collision. In practical terms, if you generated one billion UUIDs per second, it would take about 85 years to reach a 50% collision probability.

When should I use UUIDs instead of auto-incrementing IDs?

Use UUIDs when you need to generate IDs across distributed systems without coordination, when you want to prevent sequential ID enumeration for security, when merging data from multiple databases, or when creating IDs on the client side before inserting into a database. Auto-incrementing IDs are better when you need compact storage, human-readable identifiers, or guaranteed ordering without additional timestamp columns.

UUID Generator - Generate UUIDs Online

Generate version 4 UUIDs (universally unique identifiers) instantly. Create single or bulk UUIDs with options for uppercase, lowercase, and hyphen formatting. Everything runs in your browser.

What Is a UUID?

A UUID, or Universally Unique Identifier, is a 128-bit label used to uniquely identify information in computer systems. Unlike sequential identifiers assigned by a central authority, UUIDs can be generated independently by any machine or process with an extremely high guarantee that the resulting value is unique across all systems, all time, and all space. The standard is formally defined in RFC 4122 and has become one of the most widely used identification schemes in modern software development.

A UUID is represented as 32 hexadecimal digits organized into five groups separated by hyphens, following the pattern 8-4-4-4-12. A typical UUID looks like 550e8400-e29b-41d4-a716-446655440000. The total string length is 36 characters including the four hyphens. Despite their seemingly random appearance, UUIDs follow a well-defined internal structure: certain bits encode the version (which generation algorithm was used) and the variant (which UUID specification the identifier conforms to).

UUIDs were originally created by the Open Software Foundation as part of the Distributed Computing Environment. They were designed to solve a specific problem: how do you create a unique identifier without consulting a central naming authority? In a world of distributed systems, microservices, and offline-capable applications, this requirement is more relevant than ever. UUIDs allow any node in a distributed system to generate identifiers independently, with virtual certainty that no two nodes will ever produce the same value.

UUID Versions Explained

The UUID specification defines five versions, each using a different algorithm to generate the 128-bit value. Understanding the differences helps you choose the right version for your use case.

Version 1: Time-Based UUID

UUID v1 combines the current timestamp (measured in 100-nanosecond intervals since October 15, 1582) with the MAC address of the generating machine. This guarantees uniqueness as long as the clock does not go backward and the MAC address is unique. The downside is that v1 UUIDs expose both the time of creation and the hardware address of the generating machine, which can be a privacy and security concern. The timestamp is encoded in a specific layout across the first three groups of the UUID, with the version nibble (0001) embedded in the third group.

Version 2: DCE Security UUID

UUID v2 is a variant of v1 used in the Distributed Computing Environment (DCE) for security purposes. It replaces part of the timestamp with a local domain identifier (such as a POSIX UID or GID). Version 2 UUIDs are rarely used in modern systems because their specification is not fully documented in RFC 4122 and they have a much higher collision risk due to the reduced timestamp precision.

Version 3: Name-Based UUID (MD5)

UUID v3 generates a deterministic identifier by hashing a namespace identifier and a name using the MD5 algorithm. Given the same namespace and name, the resulting UUID is always identical. This is useful when you need reproducible identifiers derived from existing data, such as generating a UUID from a URL or a domain name. The namespace is itself a UUID (several standard namespaces are predefined for DNS, URLs, OIDs, and X.500 names). Because MD5 is considered cryptographically broken, UUID v5 is generally preferred for new applications.

Version 4: Random UUID

UUID v4 is the most widely used version today. It generates identifiers using random or pseudo-random numbers. Of the 128 bits, 6 are fixed (4 bits for the version number 0100 and 2 bits for the variant 10), leaving 122 bits of randomness. This produces approximately 5.3 undecillion (5.3 times 10 to the 36th power) possible values. UUID v4 is the version generated by this tool, using the Web Crypto API for cryptographically secure randomness.

Version 5: Name-Based UUID (SHA-1)

UUID v5 works identically to v3 but uses the SHA-1 hash function instead of MD5. Like v3, it produces deterministic UUIDs from a namespace and name pair. Since SHA-1 provides a stronger hash than MD5 (though SHA-1 itself is no longer considered collision-resistant for cryptographic purposes), v5 is the recommended choice for name-based UUID generation. The first 128 bits of the SHA-1 digest are used, with the version and variant bits overwritten.

UUID v4 Format and Structure

A UUID v4 follows the standard 8-4-4-4-12 hexadecimal format. The string representation consists of 32 hexadecimal characters and 4 hyphens for a total length of 36 characters. Here is how the structure breaks down:

Positions 1-8: Eight random hexadecimal digits forming the time_low field.
Positions 10-13: Four random hexadecimal digits forming the time_mid field.
Positions 15-18: The version nibble (always 4 for v4) followed by three random hexadecimal digits, forming the time_hi_and_version field.
Positions 20-23: The variant bits (10 in binary) in the first two bits of the first digit, followed by random bits for the remaining digits, forming the clock_seq_hi_and_reserved and clock_seq_low fields.
Positions 25-36: Twelve random hexadecimal digits forming the node field.

In a v4 UUID like f47ac10b-58cc-4372-a567-0e02b2c3d479, the bold digit 4 indicates version 4, and the bold letter a (binary 1010) indicates the variant. The first two bits of the variant octet are always 10, meaning the first hex digit of the fourth group will always be 8, 9, a, or b.

When to Use UUIDs

UUIDs are the right choice in several common scenarios. In distributed systems where multiple servers or services need to create records independently, UUIDs eliminate the need for a centralized ID-generation service. Each node can generate identifiers autonomously without any risk of collision, which simplifies architecture and removes a single point of failure.

UUIDs are also valuable for security. Sequential auto-incrementing IDs reveal information about your system: they expose how many records exist, allow attackers to enumerate resources by incrementing the ID, and can leak creation order. UUIDs, being random and unpredictable, make it much harder for unauthorized users to guess valid resource identifiers. This is particularly important for public-facing APIs where resource IDs appear in URLs.

Database merging and data migration are another strong use case. When combining records from multiple databases that each use auto-incrementing primary keys, ID conflicts are inevitable. If every record already has a UUID, merging is trivial because no two records will share the same identifier regardless of which database they originated from.

Client-side ID generation is increasingly common in modern web and mobile applications. With UUIDs, the client can assign an identifier to a new record before it is sent to the server. This enables optimistic UI updates, offline-first architectures, and idempotent API requests. If a network request fails and is retried, the server can detect the duplicate UUID and avoid creating a duplicate record.

UUID vs Auto-Increment IDs

Auto-incrementing integer IDs have been the default primary key strategy in relational databases for decades, and they still have legitimate advantages. They are compact (typically 4 or 8 bytes compared to 16 bytes for a UUID), human-readable, naturally ordered by creation time, and produce sequential values that are friendly to B-tree indexes. For a single-database application with no distributed components, auto-incrementing IDs are often the simpler and more performant choice.

However, UUIDs offer advantages that auto-incrementing IDs cannot match. They are globally unique without requiring database coordination, making them ideal for microservices, event sourcing, and distributed architectures. They do not expose record counts or creation order, improving security. They allow client-side generation, enabling offline-capable applications. And they make database sharding and merging straightforward because there are no ID collisions to resolve.

The performance trade-off is worth considering. Random UUIDs can cause index fragmentation in databases that use clustered indexes on the primary key, because new records are inserted at random positions rather than appended to the end. Some databases mitigate this with UUID-specific optimizations, and newer UUID formats like UUIDv7 (which includes a timestamp prefix) are designed to be naturally sortable while retaining the benefits of global uniqueness.

Collision Probability

One of the most common questions about UUIDs is whether two independently generated values could ever be the same. The answer is: theoretically yes, but practically no. UUID v4 has 122 random bits, yielding approximately 5.3 times 10 to the 36th power possible values. To put this number in perspective, there are roughly 10 to the 80th power atoms in the observable universe, and the number of possible UUID v4 values is on a comparable scale of magnitude.

The birthday problem from probability theory gives us the collision threshold. You would need to generate approximately 2.71 quintillion (2.71 times 10 to the 18th power) UUIDs before the probability of at least one collision reaches 50%. If you generated one billion UUIDs per second continuously, it would take approximately 85 years to reach this 50% threshold. For most practical applications, which generate millions or even billions of UUIDs over their lifetime, the collision probability is so small that it is effectively zero.

That said, the collision guarantee depends entirely on the quality of the random number generator. A flawed or poorly seeded random number generator can produce predictable output, dramatically increasing collision probability. This tool uses crypto.randomUUID() when available, falling back to crypto.getRandomValues(), both of which provide cryptographically secure randomness drawn from the operating system's entropy pool.

About This Tool

This UUID generator runs entirely in your browser using JavaScript. No data is sent to any server. It uses the native crypto.randomUUID() API when available in your browser, with a polyfill that uses crypto.getRandomValues() for older browsers. You can generate single UUIDs or bulk generate up to 100 at once, with options to switch between uppercase and lowercase formatting and to include or exclude hyphens. All generated UUIDs conform to the UUID v4 specification as defined in RFC 4122.

Related Tools

Hash Generator -- Generate MD5, SHA-1, SHA-256, and other hashes from text.
Password Generator -- Create strong, random passwords with customizable options.
Base64 Encoder/Decoder -- Encode and decode Base64 strings.