UUID Generator Explained — When a Random Number Isn't Unique Enough

You are building a database table and need a primary key. Your first instinct: auto-increment integers. Simple, fast, everyone understands them. Then the first time you merge two databases or expose an ID in a URL, you realize auto-increment was a mistake.

Enter the UUID — a 128-bit identifier that is practically guaranteed to be unique across every computer on Earth. Our free UUID generator creates them with one click. But what makes a UUID different from just picking a random number between one and a billion?

Why "random enough" is not enough

A random number between 1 and 1,000,000,000 has a collision probability that rises fast. With just 40,000 random picks, you have roughly a 50% chance of hitting a duplicate. That is the birthday paradox — collisions arrive way sooner than intuition expects.

A UUID v4, on the other hand, has 122 bits of randomness. That is 2¹²² possible values — roughly 5.3 × 10³⁶. To have a 50% chance of collision, you would need to generate about 2.7 × 10¹⁸ UUIDs. If you generated one billion UUIDs per second, it would take about 85 years to hit that number. You will not generate a duplicate UUID by accident.

UUID versions — v1, v4, and why v4 is the default

There are several UUID versions, but for most developers, only two matter:

UUID v1: based on timestamp + MAC address. It is unique, but it reveals when and where it was generated. If privacy matters — say, user IDs in a public API — v1 UUIDs leak information. Someone can extract the creation timestamp and potentially the machine that generated it.

UUID v4: purely random. No timestamp, no MAC address, no pattern. Just 122 random bits plus 6 version/variant bits. This is what our UUID generator produces. It is the safe default: unique, unguessable, and reveals nothing about the system that created it.

There are also v3 and v5 (name-based, deterministic) and v7 (time-ordered, newer standard), but v4 covers the vast majority of use cases.

When to use UUIDs instead of auto-increment

• Distributed systems: two servers insert records simultaneously. With auto-increment, they conflict. With UUIDs, they do not — each server generates IDs independently.
• Public-facing IDs: /users/453 tells an attacker exactly how many users you have. /users/a3f2b8c1-9d4e-4f7a-8b2c-1e5f6a7d8c9b reveals nothing.
• Database merges: combining two customer databases? UUID primary keys merge cleanly. Auto-increment integers require renumbering every foreign key reference.
• Offline-first apps: a mobile app creates records offline, then syncs. UUIDs mean no ID conflicts when the sync happens.

When NOT to use UUIDs

UUIDs are 36 characters as strings (including hyphens). That is 4× larger than a 64-bit integer in storage. If you have a billion-row table, the storage difference matters. They also fragment B-tree indexes more than sequential integers. For small, single-server apps where IDs never leave the database, auto-increment is fine.

A common mistake: generating UUIDs in application code but storing them as strings in the database. Most databases (PostgreSQL, MySQL 8+, SQLite) have native UUID types that store them as 16 bytes instead of 36 characters. Use the native type.

For generating secure passwords alongside your UUIDs, our password generator creates strong random credentials. And for basic random numbers when collision does not matter, see our random number generator.