If you've worked with any database or REST API, you've likely seen identifiers like this:

550e8400-e29b-41d4-a716-446655440000

That's a UUID — and it's not just a random string someone typed in. It's a precisely formatted, 128-bit identifier designed to be unique across the entire world without any central coordination. Here's what that means and why it matters for your applications.

What is a UUID?

UUID stands for Universally Unique Identifier. It's a 128-bit value (32 hexadecimal characters) defined in RFC 4122, formatted as five groups separated by hyphens: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

The key property of a UUID is that it can be generated independently — on a client device, in a serverless function, or across multiple distributed services — with a negligible probability of collision. You don't need a database sequence or a central authority to hand out IDs. You just generate one and use it.

That collision probability? If you generated one billion UUIDs per second for 85 years, you'd have roughly a 50% chance of seeing your first duplicate. For practical purposes, treat them as globally unique.

UUID Versions: v1, v4, and v7 Compared

There are several UUID versions, each with a different generation strategy. The three you'll encounter most often are v1, v4, and v7.

Version How it's generated Time-sortable? Primary use case
v1 Timestamp + MAC address Partially Logging, diagnostics
v4 Fully random No Database PKs (most common)
v7 Unix ms timestamp + random Yes Database PKs (modern recommended)

Why v4 became the default

v4 is fully random — no MAC address, no system clock. It's simple to implement, has no privacy concerns, and is supported by every major language and framework. When someone says "UUID" without specifying a version, they almost always mean v4.

Why v7 is the modern choice

v7 encodes a Unix millisecond timestamp in the most significant bits, so UUIDs sort chronologically. This is a significant win for database performance — B-tree indexes stay compact when new records are inserted in order, rather than scattered randomly throughout the index. If you're starting a new project, v7 is worth choosing over v4 for any indexed column.

Where UUIDs Are Used in Practice

Database Primary Keys

Auto-increment IDs work fine for single databases, but they break down in distributed systems — two separate databases can both assign ID 42. UUIDs solve this by letting each node generate its own IDs independently.

API Resource IDs

Exposing sequential IDs in URLs (/orders/1, /orders/2...) leaks information — anyone can infer how many records you have. UUID-based URLs are opaque:

GET /api/orders/550e8400-e29b-41d4-a716-446655440000

Idempotency Keys

When retrying API requests (e.g., payment processing), you can generate a UUID on the client and send it as an idempotency key. The server uses it to detect duplicate requests and return the same result without processing the operation twice.

// Browser — built-in since 2021
const id = crypto.randomUUID(); // returns a v4 UUID

Frequently Asked Questions

v4 vs v7 — which should I use?
For new projects, go with v7. The time-sortable property improves database index performance and you get chronological ordering for free. If you're maintaining an existing codebase already using v4, there's no pressing reason to migrate — v4 is perfectly solid. The main reason to switch is if you're noticing index fragmentation issues at scale.
UUIDs vs auto-increment IDs — what's the tradeoff?
Auto-increment IDs are simpler, smaller (4–8 bytes vs 16), and slightly faster to index. They work great for single-node applications. UUIDs shine in distributed systems, multi-tenant architectures, and anywhere you need to generate IDs on the client before hitting the database. The 16-byte storage cost rarely matters in practice.
Can two UUIDs ever be the same?
Theoretically, yes. In practice, it's essentially impossible for v4. The 122 random bits give you roughly 5.3 × 10³⁶ possible values. Even at massive scale, collisions won't happen. v1 has slightly different guarantees (it relies on the system clock and MAC address), but is also effectively collision-free in normal usage.

Summary

  • A UUID is a 128-bit identifier that's globally unique without central coordination
  • v4 is fully random and currently the most widely used version
  • v7 adds a millisecond timestamp prefix, enabling chronological sorting — recommended for new projects
  • UUIDs are ideal for distributed systems, public-facing resource IDs, and idempotency keys

Need to generate UUIDs right now? These tools are ready to go: