Home / Tech / UUID Generator

UUID Generator

Q: Should I store UUIDs as strings or binary?

Store as BINARY(16) in databases, not VARCHAR(36). String format ('550e8400-e29b-41d4-a716-446655440000') takes 36 bytes vs 16 bytes for binary. For a table with 10 million records, that's 200 MB wasted storage. PostgreSQL has native UUID type; MySQL 8.0+ supports UUID_TO_BIN() for efficient storage.

Q: How do UUIDs stay unique without a central server?

UUID v4 relies on cryptographic randomness across a massive possibility space (2^122 values). Even if every person on Earth (8 billion) generated 1 billion UUIDs per second for 100 years, collision probability would still be <0.00000001%. The key is using a cryptographically secure random number generator (CSPRNG), which modern browsers and languages provide by default.

Reviewed by Alex Chen, Tech Lead

Last Updated: November 2025

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit number used to identify information in computer systems without requiring a central authority. They look like this:

                    550e8400-e29b-41d4-a716-446655440000
                

This tool generates UUID v4, which uses cryptographic randomness. The structure is: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

The "4" indicates version 4 (random)
The "y" position is always 8, 9, a, or b (variant bits)
All other positions are random hexadecimal digits (0-9, a-f)
Total possible values: 2¹²² = 340 undecillion (340 with 36 zeros)

How Unique Are UUIDs?

🎲 The Numbers Are Absurd

If you generated 1 billion UUIDs per second, it would take 10.9 trillion years (773x the age of the universe) to generate all 2¹²² possible UUIDs. The probability of generating a duplicate when creating 1 billion UUIDs is approximately 1 in 2.71 quintillion.

In practice, UUID collisions are considered impossible. You're more likely to win the lottery jackpot 5 times in a row than to generate a duplicate UUID in a real-world application.

UUID Versions Explained

🔢 UUID v1 (Timestamp + MAC Address)

Pros: Time-sortable, sequential
Cons: Leaks MAC address (privacy risk), predictable (security risk)
Use: Legacy systems only

✅ UUID v4 (Random) — THIS TOOL

Pros: Privacy-safe, unpredictable, simple
Cons: Not time-sortable, random index performance
Use: General purpose, secure identifiers

🆕 UUID v7 (Timestamp + Random)

Pros: Time-sortable AND privacy-safe, better DB index locality
Cons: Requires clock synchronization
Use: Modern apps needing sortable IDs

💡 Expert Tip: UUID Storage in Databases

"Never store UUIDs as VARCHAR(36) if you have more than a few thousand records." — Alex Chen, Tech Lead

The string format (550e8400-e29b-41d4-a716-446655440000) takes 36 bytes. The binary format takes 16 bytes. For a table with 10 million records:

VARCHAR(36): 360 MB storage
BINARY(16): 160 MB storage
Savings: 200 MB (56% reduction)

PostgreSQL: Use the native UUID type.
MySQL 8.0+: Use BINARY(16) with UUID_TO_BIN() and BIN_TO_UUID().

⚠️ Common Mistakes

1. Using UUID v1 for Security-Sensitive IDs

UUID v1 exposes your MAC address and timestamp, making IDs predictable. An attacker can enumerate all your objects by guessing sequential timestamps. For session tokens, API keys, or any security-critical ID, always use UUID v4 (or better, a purpose-built secure token generator).

2. Storing UUIDs as Strings in Production Databases

VARCHAR(36) wastes 20 bytes per record (56% larger than necessary). This bloats your indexes, slows down queries, and increases storage costs. A table with 50 million UUIDs wastes 1 GB of storage and significantly degrades index performance.

3. Using Client-Generated UUIDs for Critical Operations

While UUID v4 collision probability is astronomically low, generating IDs in JavaScript means the client controls uniqueness. For financial transactions or medical records, generate IDs server-side where you have full control over randomness quality and can guarantee uniqueness via database constraints.

4. Assuming UUIDs Are "Good Enough" Primary Keys

Random UUIDs (v4) cause database index fragmentation because they're inserted in random order. For write-heavy tables (100K+ inserts/day), this can degrade performance by 30-50%. Consider sequential IDs (BIGINT AUTO_INCREMENT) or UUID v7 (time-ordered) for better index locality.

When to Use UUIDs

✅ Great For:

Distributed systems (no coordination)
Public-facing IDs (no enumeration risk)
Merging data from multiple sources
Client-side ID generation
Privacy-sensitive applications

❌ Avoid For:

High-write tables (\u003e100K inserts/day)
Human-readable IDs (invoices, orders)
Time-series data (unless using v7)
Debugging (hard to remember/type)
Very small projects (\u003c10K records)

❓ Frequently Asked Questions

What is a UUID and how unique is it?

A UUID (Universally Unique Identifier) is a 128-bit number used to identify information. UUID v4 (random) generates 2¹²² possible values (340 undecillion). The collision probability is so low (1 in 2.71 quintillion if generating 1 billion UUIDs) that it's considered practically impossible in real-world use.

What's the difference between UUID v1 and v4?

UUID v1 uses timestamp + MAC address, making IDs predictable and revealing machine info (privacy risk). UUID v4 uses cryptographic randomness, making IDs unpredictable and privacy-safe. For modern applications, v4 is recommended unless you need time-sortable IDs (use v7 in that case).

Can I use UUIDs as database primary keys?

Yes, but with caveats. UUIDs are great for distributed systems (no coordination needed) and prevent enumeration attacks. However, they're 4x larger than INT (128-bit vs 32-bit), random UUIDs hurt index performance (use UUID v7 for better locality), and they're harder to debug than sequential IDs. For web apps with <1M records, the convenience often outweighs the performance cost.

Should I store UUIDs as strings or binary?