UUID v4 Explained: What It Is and When to Use It
A practical guide to UUID v4 — how it works, when to use it as a primary key, and how it compares to other unique ID strategies.
Unique identifiers are everywhere in software — database rows, API resources, session tokens, uploaded file names. UUID v4 is one of the most commonly used formats. It’s random, collision-resistant, and standardized. This guide covers what it is, how it works, and when you should — and shouldn’t — reach for it.
What is a UUID?
UUID stands for Universally Unique Identifier. It’s a 128-bit value represented as a 32-character hex string split into five groups:
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxxThe 4 in the third group signals version 4 (random). The y in the fourth group is constrained to one of 8, 9, a, or b — that’s the variant marker. Everything else is random.
A typical UUID looks like this:
f47ac10b-58cc-4372-a567-0e02b2c3d479How UUID v4 is generated
UUID v4 uses 122 bits of randomness. The remaining 6 bits encode the version and variant. Modern browsers expose crypto.randomUUID(), which pulls from a cryptographically secure random number generator (CSPRNG) — so the output is safe even for security-sensitive uses like session tokens.
The collision probability is genuinely negligible. To reach a 50% chance of just one collision, you’d need to generate over 2.7 × 10¹⁸ UUIDs. That’s roughly 86 billion per second for a billion years.
When UUID v4 makes sense
Database primary keys. UUID v4 is a natural fit for distributed systems where multiple services generate IDs without coordinating. No central counter, no lock contention. Each node just generates and inserts.
API resource identifiers. Sequential integer IDs let clients enumerate resources by guessing — /users/1, /users/2, and so on. UUIDs make that much harder.
Correlation and trace IDs. Attach a UUID to each incoming request and log it everywhere. When something breaks across three services, you can grep logs by that ID and reconstruct the whole chain.
Uploaded file names. Naming files by UUID prevents collisions and avoids leaking the original filename in storage.
Session tokens. A UUID works as a session token when paired with a server-side lookup. For very high-security contexts, you’d want more bits — but for most apps it’s fine.
UUID v4 vs other ID strategies
| Strategy | Random? | Sortable? | Short? |
|---|---|---|---|
| UUID v4 | Yes | No | No |
| UUID v1 | No (time-based) | Yes | No |
| ULID | Yes | Yes | No |
| Nano ID | Yes | No | Yes |
| Auto-increment | No | Yes | Yes |
If you need time-ordered IDs — useful for database indexes and offset-based pagination — look at ULID or UUID v7, which embeds a timestamp prefix. If you need shorter IDs for URLs, nanoid is the usual choice. For a single server with no distribution requirements, auto-increment integers are still perfectly reasonable.
UUID v4 in databases
A few things worth knowing before you set UUID as your primary key:
Index fragmentation. B-tree indexes work best with sequential inserts. Random UUIDs scatter writes across the index, which can hurt write performance at scale. PostgreSQL’s gen_random_uuid() and MySQL 8’s UUID_TO_BIN(..., 1) both help — the latter reorders the bytes to make the UUID partially sequential. UUID v7 solves this more cleanly.
Storage size. A UUID stored as CHAR(36) takes more space than a 4-byte integer. Use the native UUID type in PostgreSQL or MySQL 8, or BINARY(16) elsewhere.
Readability in queries. UUID-keyed tables are harder to debug by hand. You can’t glance at a query result and know what you’re looking at. A short human-readable slug alongside the UUID is sometimes worth the extra column.
Need a UUID right now? The UUID Generator runs entirely in your browser — no signup, no installation. Set the count, optionally switch to uppercase, and copy them all at once.