Every UUID version — v1 through v8 — with structure diagrams, use cases, collision risk, and JavaScript code examples.
Structure
timestamp (60-bit) + clock seq (14-bit) + MAC (48-bit)
Collision risk
Very low
Advantages
Disadvantages
Best used for
Legacy systems. Avoid in new projects due to MAC address exposure.
Structure
MD5(namespace UUID + name) → UUID
Collision risk
MD5 collision risk (low for UUIDs)
Advantages
Disadvantages
Best used for
Generating UUIDs from URLs, email addresses, or other stable identifiers. Use v5 instead.
Structure
122 random bits + 4-bit version + 2-bit variant
Collision risk
Negligible (2^122 possibilities)
Advantages
Disadvantages
Best used for
Default choice for most applications. IDs for records, sessions, tokens.
Structure
SHA-1(namespace UUID + name) → UUID (top 128 bits)
Collision risk
SHA-1 — extremely low for UUID purposes
Advantages
Disadvantages
Best used for
Deterministic IDs from a namespace + name. Example: UUID for 'https://example.com' is always the same.
Structure
Unix ms timestamp (48-bit) + version (4-bit) + random (74-bit)
Collision risk
Very low (74 random bits)
Advantages
Disadvantages
Best used for
Database primary keys where sort order matters. Replaces v1 for time-ordered UUIDs.
Structure
128 bits, content defined by the implementation
Collision risk
Depends on implementation
Advantages
Disadvantages
Best used for
Experimental or vendor-specific use cases where v1–v7 don't fit.
| Version | Method | Sortable | Privacy-safe | Deterministic |
|---|---|---|---|---|
| v1 | Time + MAC | ✅ | ❌ (MAC leak) | ❌ |
| v3 | MD5 hash | ❌ | ✅ | ✅ |
| v4 | Random | ❌ | ✅ | ❌ |
| v5 | SHA-1 hash | ❌ | ✅ | ✅ |
| v7 | Time + Random | ✅ | ✅ | ❌ |
| v8 | Custom | — | — | — |
// JavaScript / Node.js (built-in, Node 15+)
import { randomUUID } from 'crypto';
const v4 = randomUUID(); // → "550e8400-e29b-41d4-a716-446655440000"
// Browser
const v4 = crypto.randomUUID();
// UUID v7 (npm: uuid package v10+)
import { v7 as uuidv7 } from 'uuid';
const v7 = uuidv7(); // → "018f0b2d-4c9e-7abc-89de-f012345678ab"
// Python
import uuid
v4 = str(uuid.uuid4()) # Random
v5 = str(uuid.uuid5(uuid.NAMESPACE_URL, 'https://example.com'))
# PostgreSQL
SELECT gen_random_uuid(); -- v4 (pg 13+)
SELECT uuid_generate_v4(); -- v4 (uuid-ossp extension)
SELECT gen_random_uuid()::text; -- as textA UUID (Universally Unique Identifier) is a 128-bit identifier standardized in RFC 4122. It is formatted as 8-4-4-4-12 hexadecimal characters separated by hyphens, for example: 550e8400-e29b-41d4-a716-446655440000. They are designed to be unique across space and time without a central authority.
Use v4 for most general purposes — it is randomly generated and has extremely low collision probability. Use v7 if you need time-ordered UUIDs for database primary keys (better index performance than v4). Use v5 if you need deterministic UUIDs from a namespace + name pair. Avoid v1 in new projects as it exposes the MAC address.
UUID v4 is purely random (122 random bits). UUID v7 encodes a Unix timestamp in the first 48 bits followed by random bits. This makes v7 UUIDs sortable by creation time, which significantly improves B-tree index performance in databases compared to random v4 UUIDs.
Practically yes. UUID v4 has 122 random bits, giving 2^122 ≈ 5.3 × 10^36 possible values. To have a 50% chance of a collision you would need to generate about 2.7 × 10^18 UUIDs — far more than any realistic application.