What is a UUID? The Developer's Guide (2026)
Walk into any backend codebase built in the last decade and you'll find IDs that look like 550e8400-e29b-41d4-a716-446655440000. These are UUIDs — 128-bit identifiers designed to be unique across systems, databases, and even galaxies. They quietly power the infrastructure of distributed applications, payment systems, and every photo upload you've ever made.
This guide explains what a UUID actually is, breaks down the five versions you need to know about, compares it to the trusty auto-increment integer, and shows you when (and when not) to reach for one.
1. The Format: 128 Bits, 36 Characters
A UUID is 16 random or structured bytes, written as 32 hex digits grouped into five segments:
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
└─8──┘ └4─┘ └4┘ └4┘ └────12────┘
- M = version digit (tells you which algorithm generated it: 1, 3, 4, 5, or 7)
- N = variant (almost always
8,9,a, orbfor "RFC 4122 variant") - The 36-character form includes four hyphens. Drop them and you get a 32-char compact form that some systems prefer.
2. Version Comparison: v1 vs v3 vs v4 vs v5 vs v7
| Version | Based on | Pros | Cons |
|---|---|---|---|
| v1 | Timestamp + MAC address | Sortable, fast to generate | Leaks MAC + creation time; not secure |
| v3 | MD5 hash of namespace + name | Deterministic — same input → same UUID | MD5 is broken; rarely used now |
| v4 | 122 bits of random data | No leakage; trivial to generate; ubiquitous | Not sortable; relies on RNG quality |
| v5 | SHA-1 hash of namespace + name | Deterministic + stronger than v3 | Still need a namespace; not random |
| v7 | ms Unix timestamp + random (RFC 9562) | Sortable, no leakage, modern best practice | Newer — older libs don't support it yet |
Reading the version digit: count the hyphens, then look at the first hex character of the third group. 550e8400-e29b-41d4-... is v4. ...-5... is v5. The 13th character (after two hyphens) is the version marker.
The variant bits are in the 17th character (the first hex of the fourth group). RFC 4122 variant values are 8, 9, a, or b. This is why you'll see 41d4-8 or 41d4-9 in nearly every UUID you've ever read.
3. Why v7 Is the New Default (Since RFC 9562, May 2024)
For two decades, v4 was the obvious choice. Then databases grew up and we hit a wall: v4 is random, which means a B-tree index has to reshuffle on every insert. With 100M rows, those random inserts kill write throughput and balloon index size.
v7 fixes this by putting a millisecond-precision Unix timestamp in the first 48 bits:
018f3e84-9c72-7xxx-Nxxx-xxxxxxxxxxxx
└────48-bit ms timestamp────┘
The result: UUIDs are still globally unique, but they're monotonically increasing for new rows, which keeps B-tree indexes happy. You get database performance close to auto-increment with the distribution-friendliness of UUIDs. If you're starting a new project in 2026, default to v7.
4. UUID vs Auto-Increment Integer
| Factor | Auto-increment | UUID (v4/v7) |
|---|---|---|
| Storage | 8 bytes (bigint) | 16 bytes + index overhead |
| Index locality | Excellent (sequential) | v4: poor. v7: excellent |
| Client-generated? | No — needs DB round-trip | Yes — offline-friendly |
| Merge across DBs | Conflicts | No conflicts |
| Leakage | Reveals row count, growth rate | v4/v7: no leakage |
| URL-friendly | /orders/48291 — guessable | /orders/550e... — unguessable |
Pick auto-increment for internal-only IDs (FK columns, join tables) where storage and speed matter. Pick UUID for anything that crosses a trust boundary — public order IDs, user-facing tokens, file uploads in a multi-tenant system, or anything synced between devices.
5. Where UUIDs Shine
- Database primary keys in distributed systems. Multiple services can insert rows without coordinating on a central ID allocator.
- Order / invoice / ticket numbers. Customers see
ORD-7f3a9b2c-...instead ofORD-48291. Harder to enumerate, harder to forge. - File deduplication. Hash a file's contents → UUID. Same file, same UUID, no matter who uploaded it.
- Event IDs in event-sourced systems. Producers and consumers reference events without a shared counter.
- Mobile & offline-first apps. Clients create UUIDs locally and sync to the server later. No "save and we'll email you an ID" dance.
6. How Unstable Is "Unique"? (Collision Math)
With 122 random bits (v4), the chance of generating two identical UUIDs is governed by the birthday paradox. The math says: to hit a 1-in-a-billion chance of any collision, you'd need to generate about 103 trillion UUIDs. As a sanity check:
Generate 1 billion UUIDs per second
Run continuously for 100 years
Total: ~3.15 × 10^18 UUIDs
Collision probability: ~10^-12 (one in a trillion)
For perspective: you'd need to run every device on Earth for decades to even approach a measurable collision rate. The RNG quality matters far more than the math — use crypto.randomUUID() in Node/browsers, never Math.random().
Generate v1, v4, and v7 UUIDs in your browser.
The UUID Generator uses your platform's cryptographic RNG, supports batch generation (1 to 1000 at a time), and lets you copy results in hyphenated, compact (32chars), or URN (urn:uuid:...) formats. Everything runs client-side — no IDs leave your machine.
7. Frequently Asked Questions
Q: Should I store UUIDs as varchar(36) or binary(16)?
If your database supports it, store as 16 bytes. MySQL's BINARY(16), PostgreSQL's native uuid type, or a varbinary column all save space and speed up comparisons. The 36-char string form is for humans and external APIs — internally, keep it binary. If you must use a string, always lowercase for consistent indexing.
Q: Are UUIDs secure as authentication tokens?
v4 UUIDs have 122 bits of entropy, which makes them unguessable in practice — so yes, a v4 can serve as a session token or share-link ID. Don't use v1 (predictable from timestamp+MAC) or v3/v5 (deterministic — anyone who knows the input can compute the ID). For anything security-sensitive, also wrap the UUID in an HMAC and check it server-side.
Q: My ORM generates v4 by default — should I switch to v7?
For new tables, yes. The migration is easy: change the generator, the data type stays the same. For existing tables with millions of v4 rows, the index is already fragmented — switching the generator only helps new inserts. Consider doing it during a planned reindex or table rewrite.
Q: Why is the first UUID example always 550e8400-...?
It comes from the original RFC 4122 spec (1998) — that exact value is shown as the canonical example in section 4.4. Decades of copy-paste later, it's become the "Hello World" of UUIDs. If you see it in production logs, someone either used a sample placeholder or hardcoded it as a fixture.
Conclusion
UUIDs look like noise, but they're a deliberate answer to a real problem: how do you generate identifiers that are unique across systems that never talk to each other? v4 has been the workhorse for two decades, but for greenfield projects in 2026, v7 is the smart default — same guarantees, better database performance, no leakage of timestamps or MAC addresses.
Use auto-increment for internal-only keys where every byte matters. Use UUIDs for anything user-facing, anything that crosses service boundaries, and anything that needs to survive merges, forks, or offline creation. And always use a cryptographically secure RNG — your future self will thank you when the audit hits.