UUID Generator Guide: UUID v1, v4, v5, v7 Explained (2026)

A UUID is a 128-bit identifier displayed as five groups of hexadecimal digits separated by hyphens, in the pattern 8-4-4-4-12 (32 hex chars + 4 hyphens = 36 characters total):

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
│        │    │    │    │
│        │    │    │    └─ 12 hex digits (node / random)
│        │    │    └────── 4 hex digits (variant + random)
│        │    └─────────── 4 hex digits (version M + random)
│        └──────────────── 4 hex digits (time mid / random)
└───────────────────────── 8 hex digits (time low / random)

The two special nibbles

• Version nibble (M): The first digit of the third group. Values: 1, 2, 3, 4, 5, 6, 7 — tells you which UUID version it is.
• Variant nibble (N): The first digit of the fourth group. For RFC 4122 UUIDs, this is always 8, 9, a, or b (binary 10xx).

Example breakdown

550e8400-e29b-41d4-a716-446655440000
                 ↑         ↑
                 version=4  variant=a (RFC 4122)

The nil UUID

The nil UUID is a special UUID with all 128 bits set to zero: 00000000-0000-0000-0000-000000000000. It is used as a sentinel or placeholder value — similar to NULL in SQL. Some systems use it to indicate "no UUID assigned yet" or as a default value in nullable UUID fields.

There are five standardised UUID versions. Each version encodes different information into the 128 bits. Here is the complete comparison:

UUID v1 — Time + MAC

UUID v1 encodes a 60-bit timestamp (in 100-nanosecond intervals since Oct 15, 1582) and the MAC address of the generating machine. While technically sortable by time, v1 exposes the machine's MAC address — a privacy concern. It also creates "hot spots" in B-tree indexes because newly generated UUIDs cluster at one end. Avoid in new projects.

UUID v4 — Pure Random

UUID v4 uses 122 random bits (the remaining 6 bits encode version and variant). It is the most widely used UUID version. It requires no coordination between systems, is completely private, and is supported by every UUID library in every language. The only downside: it is not sortable, which can cause B-tree index fragmentation in databases.

UUID v5 — Namespaced SHA-1

UUID v5 deterministically generates a UUID from a namespace UUID + a name string using SHA-1. Given the same inputs, you always get the same UUID. Use this when you need a stable identifier for the same real-world entity (e.g., always generate the same UUID for user email "alice@example.com"). Predefined namespaces: DNS, URL, OID, X.500.

UUID v7 — The Modern Choice for Databases

UUID v7 (RFC 9562, published 2024) encodes a Unix timestamp in milliseconds in the first 48 bits, followed by random bits. Because the timestamp is in the high bits, v7 UUIDs sort chronologically — solving the index fragmentation problem of v4. UUID v7 is now the recommended choice for database primary keys, replacing both v4 (no ordering) and v1 (privacy issues).

One of the most common questions about UUIDs: "Can two UUIDs ever be the same?" Technically yes, but the probability is astronomically small.

UUID v4 collision math

UUID v4 uses 122 random bits, giving 2¹²² ≈ 5.3 × 10³⁶ possible values. Using the birthday problem approximation:

P(collision) ≈ n² / (2 × 2^122)

To get a 50% chance of collision with n UUIDs generated:
n ≈ 2.71 quintillion (2.71 × 10^18)

For practical context: if you generated 1 billion UUIDs per second, it would take approximately 85 years to reach a 50% chance of even a single collision. In practice, UUID collisions are not a real engineering concern when using a cryptographically secure random number generator.

The CSPRNG requirement

The collision guarantee only holds when using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). JavaScript's crypto.randomUUID(), Python's uuid.uuid4(), and Java's UUID.randomUUID() all use CSPRNGs. Avoid Math.random()-based UUID generators — they are not cryptographically secure and have higher collision rates.

Using UUID as a database primary key is a hotly debated architectural decision. Here is an honest analysis for MySQL and PostgreSQL.

UUID vs Auto-Increment: The Trade-offs

MySQL recommendations

In MySQL (InnoDB), the primary key is the clustered index. Random UUID v4 as a PK causes severe index fragmentation because new rows are inserted at random positions in the B-tree rather than at the end. For large tables (10M+ rows), this degrades insert performance significantly. Use UUID v7 or the UUID_TO_BIN(uuid, 1) function which swaps the time components for better ordering. Store as BINARY(16), not VARCHAR(36) — saves 55% storage.

PostgreSQL recommendations

PostgreSQL has native UUID type (16 bytes). Use gen_random_uuid() for v4 (built-in since PostgreSQL 13) or the pg_uuidv7 extension for v7. PostgreSQL also supports UUIDv7 natively in PostgreSQL 17+. For high-throughput tables, prefer UUID v7 or ULID over UUID v4.

Rule of thumb

• Single-server app, < 10M rows: Auto-increment BIGINT is fine and simpler
• Distributed system / microservices: UUID v7 (best balance of all factors)
• Exposing IDs in URLs/APIs: UUID v4 (opaque) or UUID v7 (sortable)
• Need deterministic IDs: UUID v5

Short answer: yes, GUID and UUID are essentially the same thing. Here is the distinction:

Microsoft's GUID is a variant of UUID. The key differences are cosmetic: GUIDs are often displayed in uppercase with curly braces (e.g., {550E8400-E29B-41D4-A716-446655440000}). In .NET, System.Guid.NewGuid() generates a version 4 UUID under the hood. When interoperating between Microsoft systems and non-Microsoft systems, strip the braces and lowercase the hex to convert a GUID to a standard UUID.

GUID in SQL Server

SQL Server uses the UNIQUEIDENTIFIER data type for GUIDs. NEWID() generates a random GUID (UUID v4). NEWSEQUENTIALID() generates sequential GUIDs optimised for clustered index performance — the SQL Server equivalent of UUID v7. Always prefer NEWSEQUENTIALID() for clustered index primary keys in SQL Server.

Validating a UUID in your application is straightforward with a regular expression:

Standard UUID regex (case-insensitive)

/^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i

This pattern validates:

• The 8-4-4-4-12 structure with hyphens
• Version digit: 1–7 (valid UUID versions)
• Variant bits: 8, 9, a, b (RFC 4122 variant)

Version-specific validation

// UUID v4 only
/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i

// UUID v7 only
/^[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i

Generating UUIDs in code

// JavaScript (browser + Node 15+)
crypto.randomUUID()  // UUID v4, CSPRNG-backed

// Python
import uuid
uuid.uuid4()   # v4 random
uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com')  # v5 deterministic

// Java
UUID.randomUUID()  // v4

// Go
import "github.com/google/uuid"
uuid.New()  // v4