UUID Generator

UUIDs in 2026: When to Use What

A UUID (Universally Unique Identifier, also called GUID) is a 128-bit number written as 32 hex digits, conventionally grouped 8-4-4-4-12. The IETF defines several versions in RFC 4122 (1–5) and the recently-published RFC 9562 (April 2024) (6, 7, 8). For new applications in 2026, only two versions matter in practice: v4 (purely random) and v7 (timestamp + random, sortable). This generator focuses on those.

UUIDv4 — Pure Random

v4 is 122 bits of cryptographic randomness with a fixed 6-bit version/variant marker. Format: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where 4 is the version and y is one of 8, 9, a, b (the variant). Collision probability is negligible: you'd need to generate ~2.71 quintillion before reaching a 50% chance of any two matching (the birthday bound for 122 bits).

The downside: v4 IDs are random, which means new rows scatter randomly across an index. In databases that use B-tree primary key indexes (most of them), this leads to page splits, write amplification, and degraded insert throughput as the table grows. For tables that take millions of rows, v4 as a primary key becomes painful.

UUIDv7 — Sortable Time-Based

v7 (RFC 9562) prepends a 48-bit Unix millisecond timestamp to 74 bits of random data. The result is still globally unique and still 128 bits, but sorts naturally in insertion order. New rows append to the right side of the B-tree, preserving locality. Most modern frameworks and databases — Laravel, .NET 9, Linear, Stripe — have moved to v7 (or similar k-sortable IDs like ULID) by default for primary keys.

v7 leaks creation time, which is sometimes a feature (debugging, sorting, partitioning) and sometimes a privacy concern (IDs in URLs reveal account creation order). If creation order is sensitive, stick with v4 — but for backend keys, v7 is almost always the right choice.

The Other Versions

• v1 — timestamp + MAC address. Leaks hardware identity. Avoid.
• v3 — MD5 hash of a name in a namespace. Useful for deterministic IDs (always generate the same UUID for the same input). Use v5 instead — same idea, SHA-1.
• v5 — SHA-1 hash of a name in a namespace. Deterministic; same input always yields the same UUID. Useful for content-addressed IDs.
• v6 — reordered v1 to be sortable. Largely obsoleted by v7.
• v8 — custom format (you fill the bits). Escape hatch for application-specific ID schemes.
• NIL — all zeros. Sentinel value for "no UUID".

Format Variants

The same 16 bytes can be displayed several ways:

• Canonical — a1b2c3d4-e5f6-4890-abcd-ef1234567890 (36 chars).
• No hyphens — a1b2c3d4e5f64890abcdef1234567890 (32 chars). Some databases store this way; some APIs prefer it.
• Braced — {a1b2c3d4-e5f6-4890-abcd-ef1234567890} (38 chars). Common in Windows / .NET / COM contexts.
• URN — urn:uuid:a1b2c3d4-e5f6-4890-abcd-ef1234567890. Used in some XML/RDF contexts.
• Uppercase — same UUID, A-F instead of a-f.

Generating in Code

// Browser (modern)
crypto.randomUUID()                    // v4 — built-in since 2021

// Node.js
import { randomUUID } from 'crypto';
randomUUID();                          // v4

// Node.js — v7 via uuid package
import { v7 as uuidv7 } from 'uuid'; // 'uuid' v9.0.0+
uuidv7();

// Python
import uuid
str(uuid.uuid4())                      // v4
// v7 — install uuid7 package or use uuid_utils.uuid7()

// Go
import "github.com/google/uuid"
uuid.New().String()                    // v4
uuid.NewV7()                           // v7 (newer versions)

// PostgreSQL
SELECT gen_random_uuid();              // v4 (built-in)
SELECT uuidv7();                       // requires extension

// SQL Server
SELECT NEWID();                        // v4-ish (Microsoft variant)
SELECT NEWSEQUENTIALID();              // sortable, but not RFC-compliant

For non-RFC random tokens that aren't 128-bit fixed-width, see our Random Token Generator or Random String Generator — both let you choose length and charset.