What Is a UUID and Why Does Every App Use One?

For related fixes and guides, see our troubleshooting hub.

You've seen strings like this: 550e8400-e29b-41d4-a716-446655440000

That's a UUID. They appear in database primary keys, URL slugs, session cookies, file names, API responses, and a dozen other places. Here's what they are and why they're useful.

The Problem They Solve

When you have multiple systems (multiple servers, services, databases) generating records independently, you need IDs. The naive solution is an auto-incrementing number: 1, 2, 3...

But auto-increment breaks with multiple concurrent systems. If two servers both generate record ID 1045, you have a collision. You'd need a central authority to hand out sequential IDs which creates a bottleneck and a single point of failure.

UUIDs solve this by making the ID space so large that two independent systems generating UUIDs at random are astronomically unlikely to produce the same one.

What UUID Stands For

Universally Unique Identifier. Sometimes written GUID (Globally Unique Identifier) in Microsoft contexts the same concept.

The Format

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Where:

x is a hexadecimal digit (0–9, a–f)
M is the version digit (1–8)
N indicates the variant

Standard UUID: 128 bits of data, rendered as 32 hex characters with 4 hyphens = 36 characters total.

How Large Is the UUID Space?

A 128-bit UUID has 2¹²⁸ possible values:

340,282,366,920,938,463,463,374,607,431,768,211,456

That's 340 undecillion. Even generating 1 billion UUIDs per second, you'd need about 85 years to cover 1% of the space. Collision by random chance is not a practical concern.

UUID Versions

Not all UUIDs are random. There are several versions:

Version 1: Time-based

Generates the UUID from the current timestamp and the machine's MAC address. Unique across time and machines, but reveals the machine address and timestamp a privacy concern.

Version 4: Random (Most Common)

122 bits of cryptographically random data (4 bits reserved for version/variant). This is what most developers mean when they say "generate a UUID."

f47ac10b-58cc-4372-a567-0e02b2c3d479

Version 4 is what the UUID generator produces.

Version 5: Name-based (SHA-1 hash)

Deterministic the same input name always produces the same UUID. Useful when you need a stable UUID from an existing identifier (like a URL or user email) without storing the mapping.

Version 7: Time-ordered random (New, increasingly common)

The newest version, standardized in RFC 9562 (2024). Combines a millisecond timestamp prefix with random bits. This makes UUID v7 sort chronologically a significant advantage for database performance.

Why does sort order matter for databases? B-tree indexes (what most databases use) insert new values in sorted order. Random UUIDs (v4) insert at random positions, causing page splits and fragmentation. UUID v7 always inserts at the end, behaving like an auto-increment in terms of index performance.

For new projects using UUIDs as primary keys, v7 is now often recommended over v4.

When to Use UUIDs

Good fit:

Primary keys in distributed databases (no central sequence authority needed)
IDs that need to be unguessable (user IDs in URLs sequential IDs let users enumerate records)
IDs generated across multiple systems that must merge without conflict
Temporary file names for uploads (prevent collisions in shared storage)
Session identifiers, API request IDs, trace IDs

Not a good fit:

When you need a short, human-readable ID (UUID is 36 characters)
When sort order matters for database performance and you're stuck with v4 (use v7 or ULID instead)
When you're generating IDs for a single, simple database with no distribution concerns (auto-increment is simpler)

UUID vs. Other ID Systems

System	Length	Sortable	Random	Notes
Auto-increment	Short	Yes	No	Simple, enumerable
UUID v4	36 chars	No	Yes	Most common UUID
UUID v7	36 chars	Yes	Partly	Best of both worlds
ULID	26 chars	Yes	Yes	Base32, URL-safe alternative
nanoid	Configurable	No	Yes	Shorter, URL-safe
Snowflake (Twitter)	64-bit int	Yes	No	Distributed timestamp-based

Generating UUIDs

Browser (JavaScript):

crypto.randomUUID() // UUID v4, built into modern browsers

Node.js:

const { randomUUID } = require('crypto');
randomUUID(); // UUID v4

Python:

import uuid
str(uuid.uuid4())  # UUID v4
str(uuid.uuid7())  # UUID v7 (Python 3.12+)

PostgreSQL:

SELECT gen_random_uuid(); -- UUID v4 (built-in)

In the browser: The UUID generator generates UUID v4 using crypto.randomUUID() the same secure random source available in modern browsers.

Are UUIDs Secure Enough for Secrets?

UUID v4 has 122 bits of randomness (4 bits reserved). That's the same order of magnitude as many session tokens more than sufficient to be unguessable by brute force.

However, UUIDs are commonly used in contexts where they're visible (URLs, API responses). If you're using a UUID as a session token that authenticates a user, the 122 bits of randomness is fine but you'd typically use a dedicated session token library that guarantees proper entropy and provides additional features like expiry.

For non-secret IDs that just need to be unique and unguessable (document IDs in a URL, for example), UUID v4 is appropriate.

Generate UUID v4 instantly with the UUID generator. It uses your browser's crypto.randomUUID() no network call, no server, cryptographically random.