← All Guides🛠️ Developer

UUID v4: The Complete Guide to Random Identifiers

4 min read · Updated September 2026

UUID v4 (Universally Unique Identifier version 4) is the most widely used identifier format in modern software. It's random, collision-resistant, and doesn't require coordination between systems.

What Does a UUID Look Like?

550e8400-e29b-41d4-a716-446655440000

The format is 8-4-4-4-12 hexadecimal characters (32 hex digits + 4 hyphens = 36 characters total). The "4" in the third group identifies it as version 4.

How Random Is UUID v4?

UUID v4 uses 122 bits of randomness (6 bits are fixed for version/variant). The number of possible UUIDs is 2¹²² ≈ 5.3 × 10³⁶ — more than the number of grains of sand on Earth.

Collision Probability

To have a 50% chance of a single collision, you'd need to generate about 2.71 quintillion UUIDs. In practice, collisions are virtually impossible.

UUID v4 vs Auto-Increment IDs

AspectUUID v4Auto-Increment
UniquenessGlobalTable-local only
PredictabilityUnpredictableSequential/guessable
Merge dataNo conflictsConflicts likely
Index performanceSlower (random)Faster (sequential)
Storage16 bytes (or 36 chars)4-8 bytes

When to Use UUIDs

  • Distributed systems where nodes generate IDs independently
  • Public-facing URLs where you don't want guessable IDs
  • Merging data from multiple databases
  • File names, session tokens, request IDs

Generate UUIDs Instantly

Use our UUID v4 Generator to batch-generate up to 100 UUIDs per click — cryptographically secure, RFC 4122 compliant.

Worked Example: Choosing an ID Scheme for an Order System

A two-person startup is building an orders table and must choose between integer auto-increment and UUID v4. The choice ripples through the whole product:

  1. Auto-increment: order URLs look like /orders/1042. A competitor can enumerate every order, and the ID itself leaks tomorrow's sales volume
  2. UUID v4: the URL becomes /orders/9f86d081-8847-4c86-ae2a-1a8f9dd56f63 — unguessable and leak-free
  3. For the internal order_items table they keep a small integer key: millions of rows join on a 4-byte index instead of 16 bytes
  4. Every exported report includes both: the public UUID for customers, the internal integer for support staff
TableKey choiceWhy
orders (public)UUID v4Unguessable URLs, safe to expose
order_items (internal)Auto-incrementSmaller index, faster joins

The takeaway: this is not a religious choice. Use UUIDs where IDs leave your system and sequential integers where performance matters and the value stays private. You can mint test identifiers with the UUID v4 Generator.

Common Mistakes

  • Generating UUIDs with Math.random() — it is not cryptographically secure and produces predictable, collision-prone values. Use crypto.randomUUID() or an equivalent CSPRNG.
  • Assuming v1 UUIDs are private — v1 embeds the machine's MAC address and a timestamp, which can leak hardware identity. v4 is the safe default for anything user-visible.
  • Storing UUIDs as text everywhere — many databases have a native 16-byte UUID type; storing 36-character strings inflates indexes roughly 2× and slows every join.
  • Handling case and hyphens inconsistently — the same UUID compared as uppercase in one service and lowercase in another silently fails to match. Pick a canonical form and enforce it.
  • Using random v4 as the primary key of a huge append-only table — random inserts destroy B-tree locality at billions of rows; consider time-ordered UUID v7 or a hybrid integer key.

Frequently Asked Questions

Are UUID v4 values truly unique?

Unique with overwhelming probability, not certainty. With 122 random bits, a system would need to generate about 2.7 quintillion values before a collision becomes more likely than not. Treating them as unique is sound engineering.

What are the other UUID versions for?

v1 is time plus MAC address, v3 and v5 are name-based hashes, v6 and v7 are reordered time-first variants that index better, and v8 is reserved for custom schemes. For most applications, v4 for randomness or v7 for sortable keys is the right pick.

Can I use a UUID as an API key?

Yes — 122 bits of entropy makes a v4 UUID a strong, unguessable credential. As a user password, no: passwords should be user-chosen and hashed with a password-specific algorithm, and a random UUID is impossible to remember.

Do UUIDs hurt database performance?

Random v4 keys fragment indexes and reduce cache hit rates at scale, typically becoming noticeable in the tens of millions of rows. If write throughput is your bottleneck, switch to time-ordered UUIDs (v7) or keep an internal integer key alongside the public UUID.

The Bottom Line

  1. UUID v4 is 122 bits of randomness — collisions are practically impossible
  2. Use UUIDs for distributed systems and public identifiers
  3. Auto-increment is better for internal tables where sequential order matters
  4. Always use crypto.getRandomValues() for generating UUIDs in JavaScript

Disclaimer: This guide is for informational purposes only.

Joke of the Day
Sep 6

What do you call a crab that plays baseball?

100% Free, Forever

Keep Tools Free for Everyone

No paywalls, no signups, no data sold. Built by a solo developer who believes useful tools should be accessible to everyone.

Support me on Ko-fi— keep tools free

100% of proceeds go towards hosting & building more free tools.