HomeBlogWhat Is a UUID? How Unique IDs Work and …
Developer

What Is a UUID? How Unique IDs Work and When to Use Them

Every database row, API request, and file upload needs a unique ID. Auto-incrementing integers have serious problems. Here's why UUIDs solve them — and when to use UUID v4 vs other options.

👤 By 2FA.AC Team🕐 June 1, 20266 min read
What Is a UUID? How Unique IDs Work and When to Use Them
📋 In this article

Every Database Row, Every API Request, Every File — They All Need a Unique ID

Here's a problem that every developer runs into eventually: you need to create a unique identifier for something, and you need to be confident it won't collide with any other identifier — ever — across your entire system, or potentially across multiple systems that don't even talk to each other.

You could use an auto-incrementing integer. Simple, predictable, sequential. Also: a security risk (anyone can guess the next ID), a scalability problem (requires a central counter), and useless in distributed systems where multiple databases need to create IDs independently.

Or you could use a UUID.

UUIDs solve the unique ID problem elegantly. They're generated independently, require no coordination between systems, and the probability of two of them ever colliding is so small it's effectively zero. Here's how they work and when to use them.

What Is a UUID?

UUID stands for Universally Unique Identifier. It's a 128-bit number, typically displayed as 32 hexadecimal characters separated by hyphens in a specific pattern:

550e8400-e29b-41d4-a716-446655440000

That format — 8-4-4-4-12 characters — is standardized. Every UUID looks like this. The total number of possible UUIDs is 2^128, which is approximately 340 undecillion (340 followed by 36 zeros). To put that in perspective: if every person on Earth generated a million UUIDs per second for a billion years, the probability of any two being identical would still be essentially zero.

"Universally unique" isn't marketing language. It's mathematically justified.

UUID Versions — Which One Should You Use?

There are several UUID versions, each generated differently. The most commonly used are:

UUID v1 — Time-based

Generated from the current timestamp and the MAC address of the network interface. This guarantees uniqueness across machines and time, but it has a significant downside: it encodes information about when and where it was generated. If privacy matters, v1 UUIDs leak information you might not want to share.

UUID v4 — Random

Generated from random numbers. No timestamp, no MAC address, no identifiable information. Just 122 bits of randomness (the other 6 bits are fixed to indicate it's a v4 UUID). This is the version most developers reach for today — it's simple, private, and works anywhere.

The UUID Generator at 2FA.AC generates v4 UUIDs, which is the right choice for the vast majority of use cases.

UUID v5 — Name-based (SHA-1)

Generated deterministically from a namespace and a name. The same inputs always produce the same UUID. Useful when you need a consistent identifier for something — a URL, a product name, an email address — that doesn't change.

UUID v7 — Time-ordered random (newer)

A newer format that combines a timestamp prefix with random data. The timestamp makes v7 UUIDs sortable by creation time, which is useful for database primary keys where insertion order matters for performance. Growing in adoption but not yet universally supported.

Where Are UUIDs Used?

Database primary keys

Instead of auto-incrementing integers, use UUIDs as primary keys. Benefits: IDs can be generated anywhere (client, server, multiple servers) without coordination; they don't reveal record counts; they're safe to expose in URLs without leaking business information.

The tradeoff: UUIDs are larger (16 bytes vs 4 bytes for a 32-bit integer) and slightly slower to index. For most applications this doesn't matter. For very high-volume tables, it's worth considering.

Session identifiers

Session tokens, auth tokens, reset password links — anything that needs to be unguessable and unique is a good candidate for a UUID. Auto-incrementing IDs would let attackers guess other users' session IDs. UUIDs are effectively impossible to guess.

Transaction and request IDs

When a request enters your system, assign it a UUID immediately. Log that UUID with every operation related to that request. When something goes wrong, you can trace exactly what happened across multiple services by searching for that UUID. This is standard practice in distributed systems.

File names

When users upload files, don't use the original filename — it might conflict with another file, it might contain special characters, and it might reveal information you don't want in a URL. Generate a UUID for each uploaded file. a8098c1a-f86e-11da-bd1a-00112444be1e.jpg is safer and simpler than dealing with user-provided filenames.

Idempotency keys

In payment systems and other sensitive APIs, idempotency keys prevent duplicate operations. If a payment request times out and the client retries, including the same UUID as the idempotency key tells the server "this is the same payment request, don't charge twice." The UUID identifies the operation uniquely across retries.

How to Generate UUIDs

The UUID Generator at 2FA.AC generates up to 20 UUIDs at once with a single click. You can copy them individually or copy all at once. Everything runs in your browser — no server involved.

For generating UUIDs in code:

JavaScript/Node.js:
Use crypto.randomUUID() — built into modern browsers and Node.js 14.17+. No library needed.

Python:
import uuid; uuid.uuid4() — built into the standard library.

PostgreSQL:
gen_random_uuid() in PostgreSQL 13+. Or enable the uuid-ossp extension for uuid_generate_v4().

MySQL:
UUID() generates a v1 UUID. For v4, you'll need application-level generation.

UUID vs ULID vs NanoID — Which Should You Use?

UUID isn't the only option for unique identifiers. A few alternatives have gained traction:

ULID (Universally Unique Lexicographically Sortable Identifier)

Like a UUID but sortable — the first part encodes the creation timestamp, so ULIDs sort chronologically. Better for database primary keys where you want natural ordering. Less universally supported than UUIDs.

NanoID

A smaller, URL-friendly unique ID. Uses a custom alphabet (letters and numbers, no hyphens) and is shorter than a UUID by default. Good for things that appear in URLs where you want something compact but still collision-resistant. Requires a library, not a built-in.

Auto-incrementing integers

Still the right choice for many internal uses — join tables, audit logs, anything where the ID never appears in user-facing URLs and you need maximum query performance. Don't replace them with UUIDs everywhere just because UUIDs are trendy.

UUID v4 is the safe default. Use ULID when you need sortability. Use NanoID when you need URL-friendly compactness. Use integers when performance is critical and the ID stays internal.

A Note on Security

UUID v4 is generated from random numbers, but not all random number generators are equal. Math.random() in JavaScript is designed for games and simulations, not security — it can theoretically be predicted if an attacker knows enough about the environment.

For security-sensitive UUIDs (session tokens, reset links, API keys), always use a cryptographically secure random source. In browsers and modern Node.js, crypto.randomUUID() uses the OS's secure random source. The 2FA.AC UUID Generator uses crypto.getRandomValues() for the same reason — generated UUIDs are cryptographically random, not just pseudo-random.

Need UUIDs right now? Generate up to 20 at once at 2FA.AC's UUID Generator — free, instant, cryptographically secure, and completely private.

Frequently Asked Questions

🛡️

Generate UUIDs Instantly

Generate up to 20 UUID v4s at once. Copy all with one click. Free and private.

Generate UUID →