What Is a UUID and When Should You Use One?

What Is a UUID?

A UUID — Universally Unique Identifier — is a 128-bit number used to identify information in computer systems. It is designed so that any two UUIDs generated independently, anywhere in the world, will almost certainly be different.

A UUID looks like this:

550e8400-e29b-41d4-a716-446655440000

It is 32 hexadecimal characters split into five groups by hyphens, in the format 8-4-4-4-12. Despite looking random, specific bits within the UUID carry structured information about which version generated it and how.

The standard is defined in RFC 4122 (and updated by RFC 9562 in 2024), which is why you will also see UUIDs called GUIDs (Globally Unique Identifiers) — Microsoft's term for the same concept.

Why Not Just Use Sequential IDs?

Sequential integer IDs (1, 2, 3...) are simple and fast but have real limitations:

• They reveal business information. If your order IDs are sequential and a customer sees order #1043, they know you have made roughly 1,043 orders. Competitors can probe this.
• They are hard to merge. If you have two separate databases (think a merger or a sync scenario), both might have a row with ID 42. Merging requires renumbering everything.
• They require a central authority. Something has to hand out the next number. In distributed systems with multiple database shards or microservices, that central counter becomes a bottleneck.
• They are predictable. Sequential IDs make it trivial to enumerate all resources by incrementing a URL parameter.

UUIDs solve all of these because any client, server, or microservice can generate one independently without coordination.

UUID Versions Explained

There are currently eight defined UUID versions (v1–v8). You will most commonly encounter v1, v4, v5, v7, and v8.

Version 1 — Time-based + MAC Address

UUID v1 is generated from the current timestamp (100-nanosecond intervals since October 1582) and the MAC address of the machine:

c232ab00-9414-11ec-b3c8-9e6bdeced846

Pros: Can be sorted by creation time; no collision risk. Cons: Leaks the generating machine's MAC address, which is a privacy concern. The timestamp is encoded in a non-chronological byte order, making database sorting non-trivial.

Version 4 — Random

UUID v4 is 122 bits of random data, with 6 bits reserved for version and variant information:

550e8400-e29b-41d4-a716-446655440000

Pros: Simple to generate, no hardware dependency, no information leakage. Cons: Not sortable. Random insertion into B-tree indexes (like in PostgreSQL and MySQL) causes index fragmentation over time, hurting write performance at high scale.

This is the most widely used version today and the default in most libraries.

Version 5 — Namespace + SHA-1 Hash

UUID v5 is deterministic: given the same namespace UUID and the same name string, it always produces the same UUID:

// uuid v5 of "example.com" in the DNS namespace
// always produces: cfbff0d1-9375-5685-968c-48ce8b15ae17

Pros: Reproducible. You can regenerate the UUID from the input rather than storing it. Useful for deduplication and content-addressable storage. Cons: SHA-1 is cryptographically weak; use v8 if cryptographic strength matters. The input name is not recoverable from the UUID.

Version 7 — Unix Timestamp + Random (the new standard)

UUID v7 combines a 48-bit Unix millisecond timestamp with 74 bits of random data:

018e0e37-9e72-7000-b000-000000000000
↑ timestamp ↑  ↑ random ↑

Pros: Monotonically increasing within the same millisecond window, so database indexes stay ordered. Encodes time without revealing the machine. Replaces v1 for most new projects. Cons: Requires a library that supports it (RFC 9562 is recent as of 2024).

Version 8 — Custom

UUID v8 lets you define your own bit layout while conforming to the UUID format. Used for proprietary or application-specific schemes where you need the UUID structure but want to embed your own data.

Collision Probability: How Safe Is "Universally Unique"?

For UUID v4, the probability of generating two identical UUIDs is astronomically low. To have a 50% chance of a collision, you would need to generate approximately 2.71 quintillion UUIDs (2.71 × 10¹⁸).

If you generated one billion UUIDs per second, it would take about 85 years to reach that 50% collision probability. In practice, UUID v4 collisions are a non-issue for any real-world application.

When Should You Use a UUID?

Use a UUID when:

• Building distributed systems. Multiple services or database shards need to generate IDs independently without coordination.
• Merging or syncing data. UUIDs from different sources can coexist in one table without renumbering.
• Exposing IDs in URLs or APIs. Opaque IDs do not leak business metrics or enable enumeration attacks.
• Generating IDs client-side. A mobile app or browser can create a UUID before the record is even saved to a server — useful for optimistic UI updates.

Stick with sequential IDs when:

• Performance at extreme scale is critical. Sequential IDs generate perfectly ordered B-tree indexes. At millions of writes per second, this matters.
• Storage is very constrained. A 4-byte integer vs. a 16-byte UUID adds up when you have billions of rows and foreign keys everywhere.
• Human readability matters. Support tickets, order numbers, and invoice IDs are easier to communicate verbally as #1043 than as 550e8400-e29b-41d4-a716-446655440000.

A practical hybrid: use a UUID as the public-facing identifier and keep an internal sequential integer as the primary key. This is common in e-commerce and SaaS products.

UUIDs in Different Languages

// JavaScript (Node.js, using built-in crypto)
const { randomUUID } = require('crypto');
console.log(randomUUID()); // v4

# Python
import uuid
print(uuid.uuid4())  # v4
print(uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com'))  # v5

// Go — using google/uuid
import "github.com/google/uuid"
id := uuid.New() // v4

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

-- MySQL 8+
SELECT UUID();  -- returns v1

UUID vs. ULID vs. NanoID

Three common alternatives to plain sequential IDs:

ULID (Universally Unique Lexicographically Sortable Identifier) is 26-character base32, sortable, and URL-safe — a popular alternative to UUID v7.

NanoID is a compact, URL-safe random ID (~21 characters). It is not time-sorted but is smaller and more human-friendly than a UUID.

How to Generate a UUID Right Now

No library setup needed. Use the UUID Generator to instantly generate v4 UUIDs in your browser. You can copy a single UUID or generate a batch — useful when seeding databases, creating test fixtures, or initializing configuration files.

Frequently Asked Questions

Are UUIDs case-sensitive? No. 550E8400-E29B-41D4-A716-446655440000 and 550e8400-e29b-41d4-a716-446655440000 represent the same UUID. Convention is lowercase.

Should I store a UUID as a string or binary? Binary (16 bytes) is more efficient than a 36-character string. In MySQL, use BINARY(16) and convert with UUID_TO_BIN(). In PostgreSQL, use the native UUID type. Only use a VARCHAR(36) if portability or readability is a priority.

Can I use a UUID as a primary key? Yes, but prefer UUID v7 (or ULID) over v4 if you are inserting many rows. Random primary keys fragment B-tree indexes because each new insert lands in a random position rather than at the end.

Is UUID v4 truly random? It uses cryptographically secure random number generation (CSPRNG) on modern platforms. Do not use Math.random() or similar to construct UUIDs manually.

Generate a UUID instantly with the UUID Generator — no sign-up, no installation.