UUIDs Explained: v1, v4, v5, and v7 — When to Use Each

What Is a UUID?

A Universally Unique Identifier (UUID) is a 128-bit label defined in RFC 4122. Formatted as 32 hex digits in 5 groups (8-4-4-4-12), separated by hyphens:

550e8400-e29b-41d4-a716-446655440000

The design goal is that any two UUID generators can produce identifiers that will never collide — without communicating with each other. This is valuable for distributed systems, offline-first apps, and any scenario where you can't use an auto-incrementing database ID.

UUID v1 — Timestamp + MAC Address

Generated from the current time (100-nanosecond intervals since October 15, 1582) plus the MAC address of the generating machine.

f47ac10b-58cc-11ed-9b6a-0242ac120002
               ↑ version (1)

Pros: Monotonically increasing within the same machine; useful for time-ordered data.

Cons: Encodes the MAC address — a privacy concern. Sortable but not sequentially sortable in a standard UUID format (the time bits are scrambled). Rarely used in new code.

UUID v4 — Random

122 bits of cryptographically random data. The most commonly used version today.

550e8400-e29b-41d4-a716-446655440000
                ↑ version (4), 2 bits for variant

Pros: No coordination required, no privacy leakage, extremely easy to generate.

Cons: Completely random — bad for database primary keys because random UUIDs fragment B-tree indexes, causing page splits and poor cache locality. Can slow down inserts significantly on large tables.

UUID v5 — Namespace + Name Hash (SHA-1)

Deterministic: given the same namespace UUID and name, you always get the same UUID v5. Uses SHA-1 internally.

// Always produces the same output
uuidv5("https://example.com/users/42", uuidv5.URL)
// "2ed6657d-e927-568b-95e3-af7815dcb7b9"

Use when: You need to derive a consistent ID from content — deduplication, idempotent operations, content-addressed storage. Note: v5 uses SHA-1 (cryptographically weak), but since v5 UUIDs are not used for security, this is fine.

UUID v7 — Unix Time + Random (New Standard)

Draft RFC 9562 defines v7: a monotonically increasing, time-sortable UUID built from Unix milliseconds + random bits.

018e3a2f-d5a2-7c45-a7b3-8e7d5e4f3a2b
↑ Unix ms (48 bits)    ↑ random (74 bits)

Pros: Lexicographically sortable (new records sort after old ones), dramatically better database performance than v4, preserves timestamp information. This is the recommended version for new database primary keys.

Status: Native support is arriving in languages and databases. Node.js 21+ has built-in support.

Generating UUIDs in JavaScript

// v4 — built-in in Node.js 14.17+ and all modern browsers
const { randomUUID } = crypto;
randomUUID();  // "f47ac10b-58cc-41d4-a716-446655440000"

// v4 with the 'uuid' package
import { v4 as uuidv4, v5 as uuidv5 } from "uuid";
uuidv4();
uuidv5("https://example.com", uuidv5.URL);

Generating UUIDs in Python

import uuid

uuid.uuid4()  # Random v4
str(uuid.uuid4())  # As string

# v5 (namespace + name)
uuid.uuid5(uuid.NAMESPACE_URL, "https://example.com")

Database Performance: v4 vs v7

Random v4 UUIDs as primary keys on a large PostgreSQL or MySQL table cause index fragmentation: each insert goes to a random position in the B-tree, evicting pages from cache and forcing frequent page splits. At 10M+ rows, this can make inserts 5–10× slower than sequential IDs.

Solutions: use v7 UUIDs (best), use gen_random_uuid() with a separate created_at index for ordering, or use a ULID (Universally Unique Lexicographically Sortable Identifier).

Generate Bulk UUIDs

Need to generate hundreds of UUIDs at once? ToolsVito's UUID Generator produces bulk v4 UUIDs in your browser — no server, no sign-up.