What Is a UUID and Why Do Developers Use Them Everywhere?

Open any modern codebase and you will find strings like 550e8400-e29b-41d4-a716-446655440000 identifying users, orders, files and events. That is a UUID — Universally Unique Identifier — and it solves one of distributed computing's oldest problems: how do independent systems create IDs that never clash, without asking anyone?

The anatomy of a UUID

A UUID is 128 bits, written as 32 hex characters in a 8-4-4-4-12 pattern:

550e8400-e29b-41d4-a716-446655440000
              ↑ version    ↑ variant

The digit after the second dash declares the version. The one you will meet most is v4 — random: 122 of the 128 bits are filled from a cryptographically secure random source (6 bits are fixed as version/variant markers).

Can two random UUIDs collide?

Mathematically possible, practically never. With 2¹²² possibilities, you would need to generate about 2.7 quintillion UUIDs to reach a 50% chance of a single collision (the birthday paradox). Generating a billion per second, that is 85 years of continuous output — for one probable duplicate. Every UUID library treats collisions as impossible, and empirically they are right.

UUID vs auto-increment: the real trade-offs

	Auto-increment (1, 2, 3…)	UUID v4
Needs central coordination	Yes — the database issues them	No — anyone can mint
Generated offline / client-side	No	Yes
Leaks information	Yes — count, order, growth rate	No
Guessable	Trivially (/user/42 → /user/43)	No
Size	4–8 bytes	16 bytes
Index locality	Excellent (sequential)	Poor (random) — can fragment B-tree indexes
Readable / typeable	Easy	Painful

The security row deserves emphasis: sequential IDs enable enumeration attacks — increment the number in a URL and walk through every record. Exposed sequential IDs also leak business metrics (order #10452 today, #10613 next week = ~23 orders/day). UUIDs eliminate both issues.

When UUIDs are the wrong choice

• Heavy write, index-sensitive tables — random keys scatter inserts across the index. Newer formats like UUIDv7 (time-ordered, standardised 2024) fix this by putting a timestamp in the high bits.
• Human-facing references — nobody reads a UUID over the phone. Use short codes for support tickets and coupon codes.
• Tiny embedded contexts — 16 bytes matters at scale.

UUID vs GUID

The same thing. GUID (Globally Unique Identifier) is Microsoft's historical name for the identical RFC 9562 standard. Any system asking for a GUID accepts a UUID.

Generating UUIDs

Every language ships a generator (crypto.randomUUID() in JavaScript, uuid4() in Python). Need a batch for test data, database seeding or documentation? Our UUID Generator produces up to 500 cryptographically random v4 UUIDs at once, with optional uppercase — generated locally in your browser.

Frequently asked questions

Are UUIDs secure enough to act as secret tokens? UUID v4 has 122 random bits — unguessable in principle. But use purpose-built random strings for session tokens: some UUID implementations historically used weak randomness, and secrets deserve a type that says "secret."

What are UUID versions 1, 5 and 7? v1: timestamp + MAC address (leaks both — mostly avoided). v5: deterministic, hashed from a name — same input, same UUID. v7: timestamp-prefixed random — sortable by creation time, the modern default for database keys.

Should I store UUIDs as strings or binary? Binary (16 bytes) where the database supports it — native UUID types in Postgres, BINARY(16) in MySQL. String storage costs 36 bytes plus slower comparisons.