UUID Generator: The Complete Guide

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit number used to uniquely identify information in computer systems. The term UUID is standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). When generated according to the standard, UUIDs are practically unique across space and time — no central authority is needed to coordinate them.

The most common representation is a 36-character hexadecimal string with four hyphens, like 550e8400-e29b-41d4-a716-446655440000. Each UUID is self-contained: it carries no inherent meaning about the object it identifies, but it can be relied upon to never collide with another UUID, even one generated on a different system.

UUIDs are defined in RFC 4122. There are multiple versions with different generation algorithms, each suited to different use cases.

UUID Format & Structure

A standard UUID is formatted as 8-4-4-4-12 hexadecimal digits:

xxxxxxxx-xxxx-Vxxx-Yxxx-xxxxxxxxxxxx

Where:
  x = any hex digit (0-9, a-f)
  V = version number (1, 4, or 7)
  Y = variant bits (determines layout)

Let's break down an example UUID 550e8400-e29b-41d4-a716-446655440000:

The version digit tells you how the UUID was generated. For example, 41d4 starts with 4, indicating this is a UUID v4 (random). The variant digit (a in this case, binary 10xx) indicates the RFC 4122 layout.

UUID Versions Compared

Our generator supports three UUID versions. Each has different characteristics:

UUID v1 — Time-Based

UUID v1 combines the current timestamp (100-nanosecond intervals since October 15, 1582) with the machine's MAC address. This makes v1 UUIDs sortable by creation time, but the MAC address inclusion raises privacy concerns. For this reason, many implementations now use a random node instead of the actual MAC.

// UUID v1 examples
c0a8a1b0-1234-11ec-9abc-00155d3b4c5a
// ^timestamp^   ^v1^   ^clock^  ^node^

UUID v4 — Random

UUID v4 generates 122 bits of randomness (6 bits are reserved for version/variant). With crypto.getRandomValues(), our generator uses cryptographically strong randomness. The probability of a collision is astronomically low — you would need to generate billions of UUIDs per second for centuries to have a reasonable chance of a single collision.

// UUID v4 examples
550e8400-e29b-41d4-a716-446655440000
f47ac10b-58cc-4372-a567-0e02b2c3d479

UUID v7 — Time-Ordered Random

UUID v7 is the newest standard (proposed in RFC 9562). It combines a Unix timestamp in milliseconds (48 bits) with random data (74 bits). The timestamp prefix makes UUIDs monotonically increasing, which dramatically improves B-tree index performance in databases like PostgreSQL and MySQL. Unlike v1, v7 does not expose the MAC address.

// UUID v7 examples (first 12 chars = timestamp)
018f3a6e-1b3c-7a45-b123-456789abcdef
// ^timestamp^  ^v7^  ^random^

When to Use Each Version

Use UUID v4 When:

• You need the simplest, most widely supported option
• You are generating anonymous IDs for client-side use
• Privacy is a concern (no MAC address exposure)
• You do not need sortable IDs
• Example: session tokens, event IDs, correlation IDs

Use UUID v1 When:

• You need time-sortable identifiers
• You are working in a distributed system where order matters
• The MAC address identification is acceptable (or randomized node is used)
• Example: logging sequences, distributed transactions

Use UUID v7 When:

• You need database-primary-key-friendly UUIDs (monotonically increasing)
• You want privacy (no MAC) with sortability
• You are building new systems and want the "best of both worlds"
• Example: primary keys in PostgreSQL, time-series event IDs

Practical Examples

Generating IDs for a Database

When inserting records into a database, using UUID v7 as the primary key gives you both uniqueness and efficient B-tree indexing:

-- PostgreSQL table with UUID primary key
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- With UUID v7 (better index performance)
-- Use our tool to generate v7 UUIDs and insert them sequentially

Creating Correlation IDs for Microservices

UUIDs are perfect for tracing requests across microservices. Generate one v4 UUID per request and pass it through every service call:

// API gateway generates a correlation ID
const correlationId = crypto.randomUUID();
// Result: "f47ac10b-58cc-4372-a567-0e02b2c3d479"

// Pass in HTTP headers
fetch('/api/orders', {
  headers: {
    'X-Correlation-ID': correlationId
  }
});

// All downstream services log this ID for traceability

Bulk Generation for Testing

Use the quantity selector to generate 50 or 100 UUIDs at once, then copy them all for use in test fixtures:

// Test fixture with 5 UUIDs
const testIds = [
  "550e8400-e29b-41d4-a716-446655440000",
  "6ba7b810-9dad-11d1-80b4-00c04fd430c8",
  "6ba7b811-9dad-11d1-80b4-00c04fd430c8",
  "6ba7b812-9dad-11d1-80b4-00c04fd430c8",
  "f47ac10b-58cc-4372-a567-0e02b2c3d479"
];

Best Practices

• Use cryptographic randomness: Always use crypto.randomUUID() (or our tool which uses crypto.getRandomValues()). Avoid Math.random() for UUIDs — it is not cryptographically secure.
• Consider index performance: If storing UUIDs as database primary keys, prefer v7 or v1 over v4 to avoid index fragmentation, especially for large tables.
• Store as binary for space: A UUID string takes 36 bytes. In PostgreSQL, use the uuid type (16 bytes). In other databases, store UUIDs as BINARY(16) to save 55% space.
• Do not use UUIDs as secrets: UUIDs are identifiers, not security tokens. They are predictable (v1, v7) or not truly random enough (v4) for authentication or access control.
• Use v4 for anonymity: UUID v1 contains the MAC address, which can identify the machine that generated it. Use v4 or v7 if privacy matters.
• Beware of version interoperability: Some older systems only support UUID v4. Check library compatibility before choosing v7 for cross-platform projects.