What Is a UUID v4 and When Should You Use It?

You've seen them before. Those impossibly long strings of letters and numbers lurking in URLs, database rows, and API responses. Something like 550e8400-e29b-41d4-a716-446655440000. They look like a cat walked across a keyboard, but they're actually one of the most useful tools in a developer's toolkit.

Let's break down what UUID v4 is, why it exists, and when you should (and shouldn't) reach for one.

So... What Exactly Is a UUID?

UUID stands for Universally Unique Identifier. It's a 128-bit value typically shown as a 36-character string with hyphens: 8-4-4-4-12 hex digits.

550e8400-e29b-41d4-a716-446655440000

Think of it like a Social Security Number, but for data. Except instead of 9 digits, you get 32 hex characters, and instead of the government assigning them, anyone can generate one at any time, anywhere, and it'll be unique.

There are several UUID versions, each with a different recipe:

• v1 — Uses your computer's timestamp and MAC address (a bit like a name tag that says when and where).
• v3 — Hashes a namespace + name with MD5.
• v4 — Almost entirely random. This is the one everyone uses.
• v5 — Like v3, but uses SHA-1 instead.
• v7 — The new kid on the block: timestamp + random data, so they sort by creation time.

How UUID v4 Actually Works

Of those 128 bits, 122 are randomly generated. The remaining 6 bits are reserved to identify the version (v4) and variant (RFC 4122). That gives you 2¹²² possible values — roughly 5.3 x 10³⁶. That's 5.3 undecillion. Yes, that's a real word.

You can spot a v4 UUID by the 4 at the start of the third group:

550e8400-e29b-41d4-a716-446655440000
                ^
          "Hey, I'm version 4!"

Will I Ever Get a Duplicate?

Short answer: no. The math is overwhelmingly in your favor. For all practical purposes, UUID v4 collisions don't happen. You're more likely to be struck by a meteorite while winning the lottery.

Generating UUIDs — It's Easier Than You Think

JavaScript (Browser)

Modern browsers have this built right in:

// One line. That's it. Seriously.
const id = crypto.randomUUID();
// "3b241101-e2bb-4d7a-8702-9e057c10f73a"

// Need to support older browsers? Here's a fallback:
function uuidv4() {
  return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(
    /[xy]/g,
    function (c) {
      const r = (Math.random() * 16) | 0;
      const v = c === 'x' ? r : (r & 0x3) | 0x8;
      return v.toString(16);
    }
  );
}

Node.js

import { randomUUID } from 'node:crypto';
const id = randomUUID();
// "1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed"

Python

import uuid
id = uuid.uuid4()
print(id)  # e.g. "6ba7b810-9dad-11d1-80b4-00c04fd430c8"

PostgreSQL

-- Built-in since PostgreSQL 13
SELECT gen_random_uuid();

-- Or with the extension for older versions
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
SELECT uuid_generate_v4();

When UUIDs Are Your Best Friend

• Distributed systems: When multiple servers need to create IDs independently without stepping on each other's toes. No central ID counter needed!
• Security: Auto-increment IDs are predictable. If a user sees /users/1041, they can guess /users/1042 exists. UUIDs? Good luck guessing /users/3b241101-e2bb-4d7a-8702-9e057c10f73a.
• Client-side ID generation: You can create the ID in the browser before even talking to the server. Great for optimistic UI updates and offline-first apps.
• Merging databases: Moving data between environments? UUIDs won't collide. Auto-increment IDs absolutely will.

When UUIDs Are Overkill

• Index performance: Because v4 UUIDs are random, inserting them into a database index causes random I/O instead of nice sequential writes. This can slow down large tables significantly.
• Readability: Nobody wants to read 550e8400-e29b-41d4-a716-446655440000 aloud in a support call. For user-facing IDs (like order numbers), use something shorter.
• Simple apps: If you've got one database and no distributed concerns, a plain old auto-increment ID is simpler and faster.

The New Hotness: UUID v7

UUID v7 (RFC 9562, published in 2024) is like v4's cooler younger sibling. It embeds a timestamp in the first 48 bits, which means your IDs are roughly sortable by creation time. Database indexes love sequential data, so v7 gives you the best of both worlds: uniqueness AND performance.

Storing UUIDs: Don't Use VARCHAR!

Always store UUIDs in their native binary format when your database supports it:

-- PostgreSQL: native uuid type (16 bytes, efficient)
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email TEXT NOT NULL
);

-- MySQL: BINARY(16) for performance
CREATE TABLE users (
  id BINARY(16) PRIMARY KEY,
  email VARCHAR(255) NOT NULL
);
INSERT INTO users (id, email)
VALUES (UUID_TO_BIN(UUID(), true), 'user@example.com');

Storing UUIDs as VARCHAR(36) wastes over twice the space and slows down comparisons. If your ORM defaults to string storage, override it. Your future self will thank you.

Quick Reference Table

Wrapping Up

UUID v4 is still one of the most practical ways to generate unique IDs in distributed systems. No coordination needed, virtually zero collision risk, and every major language and database supports it out of the box. Just be mindful of storage costs and index performance — and give UUID v7 a serious look if you're starting something new.

Now go forth and generate some beautifully random identifiers!