UUID v4: The Complete Guide to Random Identifiers
UUID v4 (Universally Unique Identifier version 4) is the most widely used identifier format in modern software. It's random, collision-resistant, and doesn't require coordination between systems.
What Does a UUID Look Like?
The format is 8-4-4-4-12 hexadecimal characters (32 hex digits + 4 hyphens = 36 characters total). The "4" in the third group identifies it as version 4.
How Random Is UUID v4?
UUID v4 uses 122 bits of randomness (6 bits are fixed for version/variant). The number of possible UUIDs is 2¹²² ≈ 5.3 × 10³⁶ — more than the number of grains of sand on Earth.
Collision Probability
To have a 50% chance of a single collision, you'd need to generate about 2.71 quintillion UUIDs. In practice, collisions are virtually impossible.
UUID v4 vs Auto-Increment IDs
| Aspect | UUID v4 | Auto-Increment |
|---|---|---|
| Uniqueness | Global | Table-local only |
| Predictability | Unpredictable | Sequential/guessable |
| Merge data | No conflicts | Conflicts likely |
| Index performance | Slower (random) | Faster (sequential) |
| Storage | 16 bytes (or 36 chars) | 4-8 bytes |
When to Use UUIDs
- Distributed systems where nodes generate IDs independently
- Public-facing URLs where you don't want guessable IDs
- Merging data from multiple databases
- File names, session tokens, request IDs
Generate UUIDs Instantly
Use our UUID v4 Generator to batch-generate up to 100 UUIDs per click — cryptographically secure, RFC 4122 compliant.
Worked Example: Choosing an ID Scheme for an Order System
A two-person startup is building an orders table and must choose between integer auto-increment and UUID v4. The choice ripples through the whole product:
- Auto-increment: order URLs look like
/orders/1042. A competitor can enumerate every order, and the ID itself leaks tomorrow's sales volume - UUID v4: the URL becomes
/orders/9f86d081-8847-4c86-ae2a-1a8f9dd56f63— unguessable and leak-free - For the internal
order_itemstable they keep a small integer key: millions of rows join on a 4-byte index instead of 16 bytes - Every exported report includes both: the public UUID for customers, the internal integer for support staff
| Table | Key choice | Why |
|---|---|---|
| orders (public) | UUID v4 | Unguessable URLs, safe to expose |
| order_items (internal) | Auto-increment | Smaller index, faster joins |
The takeaway: this is not a religious choice. Use UUIDs where IDs leave your system and sequential integers where performance matters and the value stays private. You can mint test identifiers with the UUID v4 Generator.
Common Mistakes
- Generating UUIDs with
Math.random()— it is not cryptographically secure and produces predictable, collision-prone values. Usecrypto.randomUUID()or an equivalent CSPRNG. - Assuming v1 UUIDs are private — v1 embeds the machine's MAC address and a timestamp, which can leak hardware identity. v4 is the safe default for anything user-visible.
- Storing UUIDs as text everywhere — many databases have a native 16-byte UUID type; storing 36-character strings inflates indexes roughly 2× and slows every join.
- Handling case and hyphens inconsistently — the same UUID compared as uppercase in one service and lowercase in another silently fails to match. Pick a canonical form and enforce it.
- Using random v4 as the primary key of a huge append-only table — random inserts destroy B-tree locality at billions of rows; consider time-ordered UUID v7 or a hybrid integer key.
Frequently Asked Questions
Are UUID v4 values truly unique?
Unique with overwhelming probability, not certainty. With 122 random bits, a system would need to generate about 2.7 quintillion values before a collision becomes more likely than not. Treating them as unique is sound engineering.
What are the other UUID versions for?
v1 is time plus MAC address, v3 and v5 are name-based hashes, v6 and v7 are reordered time-first variants that index better, and v8 is reserved for custom schemes. For most applications, v4 for randomness or v7 for sortable keys is the right pick.
Can I use a UUID as an API key?
Yes — 122 bits of entropy makes a v4 UUID a strong, unguessable credential. As a user password, no: passwords should be user-chosen and hashed with a password-specific algorithm, and a random UUID is impossible to remember.
Do UUIDs hurt database performance?
Random v4 keys fragment indexes and reduce cache hit rates at scale, typically becoming noticeable in the tens of millions of rows. If write throughput is your bottleneck, switch to time-ordered UUIDs (v7) or keep an internal integer key alongside the public UUID.
The Bottom Line
- UUID v4 is 122 bits of randomness — collisions are practically impossible
- Use UUIDs for distributed systems and public identifiers
- Auto-increment is better for internal tables where sequential order matters
- Always use crypto.getRandomValues() for generating UUIDs in JavaScript
Disclaimer: This guide is for informational purposes only.
Related Free Tools
Put this guide into practice with our free browser-based tools — no signup, no upload, 100% local processing.