What Is a UUID? Complete Guide to UUID Versions

A UUID (Universally Unique Identifier) is a 128-bit label used to uniquely identify information in computer systems without requiring a central registration authority. Standardized by RFC 4122 and later by RFC 9562, UUIDs are formatted as 32 hexadecimal digits displayed in five groups separated by hyphens — for example: 550e8400-e29b-41d4-a716-446655440000.

UUIDs solve one of the most fundamental challenges in distributed computing: generating identifiers that are unique across space and time without coordination between the systems creating them. This makes them indispensable for microservices, distributed databases, event-driven architectures, and any system where multiple nodes must independently generate non-colliding identifiers.

The probability of generating a duplicate UUID v4 is astronomically small — roughly 1 in 2^122 (about 5.3 × 10^36). To put this in perspective, you would need to generate 1 billion UUIDs per second for about 85 years to have a 50% probability of a single collision.

UUID v1 is generated using a combination of the current timestamp and the MAC address of the machine creating it. This means v1 UUIDs are inherently sortable by creation time and can reveal information about when and where they were created. They are useful in scenarios where chronological ordering matters, but the MAC address exposure may be a privacy concern.

UUID v4 is the most widely used version, generated entirely from random or pseudo-random numbers. Each v4 UUID has 122 bits of randomness, making collisions virtually impossible. This version is ideal for general-purpose identification where no temporal ordering is needed — database primary keys, session tokens, API request identifiers, and correlation IDs across microservices.

UUID v7 is a newer format defined in RFC 9562 that embeds a Unix timestamp in the first 48 bits, followed by random data. This gives v7 UUIDs the best of both worlds: they are sortable by creation time (like v1) while maintaining strong randomness (like v4). UUID v7 is increasingly recommended for database primary keys because time-sorted keys improve B-tree index performance.

Nil UUID (00000000-0000-0000-0000-000000000000) is a special UUID where all 128 bits are set to zero. It is used as a sentinel value — similar to null — to indicate an uninitialized, missing, or default identifier. Many systems use the Nil UUID as a placeholder in database fields or API responses.

GUID (Globally Unique Identifier) is Microsoft's implementation of UUIDs. While functionally equivalent, GUIDs traditionally use a mixed-endian byte order and may be displayed in uppercase. In practice, the terms UUID and GUID are used interchangeably in most modern software contexts.

Choose UUID v4 when you need a general-purpose unique identifier with no special requirements for ordering or traceability. It is the default choice for most applications — session IDs, API keys, database records, file naming, and any scenario where uniqueness without predictability is the goal.

Choose UUID v7 when you need time-sortable identifiers, particularly for database primary keys. Because v7 UUIDs start with a timestamp, they maintain chronological order when inserted into B-tree indexes, dramatically reducing page splits and improving write performance in PostgreSQL, MySQL, and other relational databases.

Choose UUID v1 when you need to extract the exact creation timestamp from the identifier itself, or when operating in environments where MAC-based uniqueness is acceptable. Note that v1 is being superseded by v7 in most new projects.

Use Nil UUID as a default or placeholder value. For example, when an API field requires a UUID but no valid identifier has been assigned yet, the Nil UUID clearly communicates 'no value' without ambiguity.

Using UUIDs as primary keys is common in distributed systems but requires careful consideration. Random UUIDs (v4) can cause index fragmentation in B-tree indexes because new values are scattered randomly across the index space. UUID v7 solves this by ensuring new identifiers are always larger than previous ones, maintaining insertion order.

In PostgreSQL, use the native uuid data type rather than varchar — it stores UUIDs in 16 bytes instead of 36 bytes for the string representation. In MySQL, store UUIDs as BINARY(16) for optimal storage and index performance, or use the built-in UUID functions available in MySQL 8.0+.

For high-throughput systems, consider generating UUIDs at the application level rather than in the database. This reduces database load and allows the application to know the identifier before the INSERT operation completes — useful for optimistic concurrency patterns and event sourcing.

Zutily's free UUID Generator supports all major UUID versions — v1, v4, v7, Nil, and GUID — with batch generation of up to 1,000 identifiers at once. You can toggle uppercase formatting, remove hyphens for compact representation, and copy or download results with a single click.

All UUID generation happens entirely in your browser using the Web Crypto API, ensuring that your identifiers are cryptographically secure and that no data is ever sent to or stored on our servers. Whether you need a single UUID for testing or a thousand for database seeding, Zutily delivers instant results with zero setup.