If you've worked on any backend system, database schema, or REST API, you've seen UUIDs everywhere. They look like this:
550e8400-e29b-41d4-a716-446655440000
They're used as unique identifiers — primary keys in databases, request IDs in logs, resource identifiers in APIs, file names for uploaded assets. They're everywhere because they solve a fundamental problem: how do you generate an ID that's guaranteed to be unique, even across multiple servers, databases, and systems — without needing a central coordinator to hand them out?
That's the core value of a UUID.
What Does UUID Stand For?
UUID stands for Universally Unique Identifier. The standard is defined in RFC 4122. A UUID is a 128-bit number, typically represented as 32 hexadecimal digits displayed in five groups separated by hyphens: 8-4-4-4-12.
The "universally unique" part is key. UUIDs are designed so that two independently generated UUIDs will almost certainly never be the same — without any communication between the systems generating them.
Generate a UUID
UUID Generator
Generate unique version 4 UUIDs (Universally Unique IDs).
UUID Versions: What's the Difference?
Not all UUIDs are the same. There are several versions, each generated differently:
| Version | How It's Generated | Best Used For |
|---|---|---|
| v1 | Timestamp + MAC address | When time-ordering matters, but privacy is less critical |
| v3 | MD5 hash of a namespace + name | Deterministic IDs from known inputs (legacy) |
| v4 | Random | General purpose unique IDs (most common) |
| v5 | SHA-1 hash of a namespace + name | Deterministic IDs from known inputs (preferred over v3) |
| v7 (newer) | Timestamp + random | Database-friendly: sortable by creation time |
UUID v4 is what you want most of the time. It's completely random (except for four bits that identify the version), requires no network access, no clock, and no knowledge of other generated IDs.
UUID v7 is gaining popularity for databases because it's sortable — the timestamp prefix means newer IDs sort after older ones, which is better for B-tree index performance than completely random v4 IDs.
Real-World Uses for UUIDs
Database Primary Keys
Instead of auto-incrementing integers (1, 2, 3...), many systems use UUIDs as primary keys. The advantage: you can generate the ID client-side before inserting the record, which simplifies certain distributed workflows.
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email TEXT NOT NULL,
created_at TIMESTAMPTZ DEFAULT now()
);
API Resource Identifiers
REST APIs often use UUIDs in URLs to identify resources:
GET /api/users/550e8400-e29b-41d4-a716-446655440000
This is better than sequential integers because it doesn't expose how many records you have, and it prevents enumeration attacks (where someone just tries 1, 2, 3 to access other users' data).
File Naming for Uploads
When users upload files, giving them UUID-based names prevents collisions and avoids exposing original filenames:
uploads/7c9e6679-7425-40de-944b-e07fc1f90ae7.png
Request and Trace IDs
Distributed systems use UUIDs to trace requests across multiple services:
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
UUIDs vs. Sequential IDs: When to Use Which
| Sequential Integer | UUID v4 | |
|---|---|---|
| Size | 4–8 bytes | 16 bytes |
| Readability | Easy (1, 2, 3) |
Hard |
| Sortable | ✅ Yes | ❌ No (random) |
| Guessable | ✅ Yes (security risk) | ❌ No |
| Distributed generation | ❌ Needs coordination | ✅ Any machine |
| Database index efficiency | ✅ Excellent | ⚠️ Moderate (v4 random) |
For most modern applications — especially those with distributed writes, multiple services, or public-facing APIs — UUIDs are the better choice despite the size overhead.
Privacy When Generating UUIDs
UUID generation should always be a local operation. There's no reason to send data to a remote server to get a UUID.
- v4 UUIDs are completely random — there's nothing to "send" to a server anyway.
- v1 UUIDs embed your MAC address in the ID. Generating these on a cloud service means that service sees your device's MAC address.
- v5 UUIDs are generated from a namespace and a name — if that name is confidential (like an internal user ID or email), generating it remotely exposes that data.
FluxToolkit's UUID generator runs entirely in your browser using the browser's cryptographically secure random number generator (crypto.getRandomValues()). Nothing is sent to our servers.
Frequently Asked Questions
Can two UUIDs ever be identical?
Theoretically, yes — but the probability is astronomically small. With v4 UUIDs, the chance of two UUIDs colliding is roughly 1 in 5.3 × 10³⁶. In practice, you'll never see it.
Are UUIDs safe to use in public URLs?
Yes. Because they're not sequential or guessable, UUIDs don't expose the size of your database or allow enumeration. They're a common and recommended approach for public-facing resource identifiers.
What's the difference between UUID and GUID?
They're effectively the same thing. GUID (Globally Unique Identifier) is Microsoft's term for the same standard. A GUID and a UUID are both 128-bit identifiers following RFC 4122.
Should I use UUID v4 or v7 for database keys?
If you're on a modern Postgres or MySQL setup and care about index performance on large tables, v7 is worth considering — it's sortable by creation time, which keeps B-tree indexes from fragmenting. For most applications, v4 is perfectly fine.
Does FluxToolkit log the UUIDs I generate?
No. UUIDs are generated locally in your browser and never transmitted to our servers.
Related Articles
Strong Passwords and Cryptographic Hashes — UUIDs and passwords both serve as secure unique identifiers.
A Complete Guide to Decoding JWT Tokens — JWTs often use UUIDs as subject identifiers in their payload.
JSON Formatter and Validator — UUID fields appear constantly in JSON API responses.
Unix Timestamp Converter — UUID v1 uses timestamps — understand the connection.
SHA-256 vs MD5 vs bcrypt — UUIDs and hashes both serve as unique identifiers in different contexts.
Number Base Converter — UUID components are represented in hexadecimal.