What Is a UUID and When Should You Use One?

A UUID (Universally Unique Identifier) is a 128-bit identifier almost guaranteed to be unique without a central coordinator. The form you see most is v4: 3f25ab1c-9d4e-4b8a-9c2f-1a2b3c4d5e6f.

UUID format dissected

The 36 characters are 32 hex digits in five groups (8-4-4-4-12) plus four hyphens. The third group's first digit encodes the version; the fourth group's first digit encodes the variant. So every v4 UUID has a 4 in the version slot and an 8, 9, a, or b in the variant slot.

The versions explained

v1 — time + MAC address; leaks the machine and clock.
v3 / v5 — name-based (MD5 / SHA-1); deterministic from a name + namespace.
v4 — random; the common default for app IDs.
v6 / v7 — time-ordered; sortable like a timestamp, useful for database keys.

Why use UUIDs

Distributed systems — two servers can mint IDs without colliding.
Non-sequential — harder to guess than user/1, user/2.
No coordination — no central ID service needed.

v4 vs the rest

v4 is random and the most common for app IDs. v1 is time-plus-MAC based (it leaks the machine). For application primary keys, v4 is the safe default — or v7 if you want sortable keys.

The collision math

A v4 UUID has 122 random bits. The probability of a collision only becomes likely after generating about 2.6 quintillion IDs. For any realistic application, "practically unique" is the correct mental model.

UUIDs in databases

UUIDs avoid cross-node collisions but are larger (16 bytes vs 4–8 for an integer) and can fragment indexes because they are not sequential. v7's time-ordered layout mitigates the fragmentation problem.

When NOT to use UUIDs

For tiny tables, short counters are simpler and more compact. And never use a UUID where a sequential integer would make pagination or range scans dramatically faster — unless you choose a time-ordered variant.

Generating them

The DevToolbox UUID Generator creates 1 to 100 v4 UUIDs at once with one-click copy. No network, so the values are produced locally.

Pick how many you need (1 to 100).
Click generate.
Copy individually or all at once.

For database primary keys, weigh UUIDs against sequential BIGINTs: UUIDs avoid collisions across nodes but are larger and fragment indexes more.

Can two UUIDs collide?: In practice, no — the space is astronomically large. "Practically unique" is the correct mental model.
Are these cryptographically safe?: Browser-generated v4 UUIDs use a strong RNG and are fine for identifiers, not for security tokens.

UUIDs in URLs (are they safe?)

UUIDs are sometimes used as public resource identifiers (e.g. /invoice/3f25ab1c-…). They are unguessable, which is good, but they are also opaque — users can't remember or type them. Use them where uniqueness matters more than readability.

Canonical form and case

UUIDs are case-insensitive in theory, but canonical form uses lowercase hex and the standard hyphen grouping. Normalizing on input avoids duplicate records that differ only by case or grouping.

Generating UUIDs in popular languages

Python — uuid.uuid4().
JavaScript — crypto.randomUUID() (modern browsers and Node).
Java — UUID.randomUUID().
Postgres — the uuid type with gen_random_uuid().

UUIDs and privacy (v1 leaks MAC)

Version-1 UUIDs embed the machine's MAC address and a timestamp. On a private network that can identify a device. For anything public-facing, stick with random v4 or time-ordered v7.

UUIDs as primary keys: the index caveat

Random UUIDs scatter inserts across an index, causing page splits and slower writes compared to sequential integers. If write volume is high, consider time-ordered UUIDs (v6/v7) or a sequential key with a UUID as a public alias.

Sortable UUIDs (v6 and v7)

Versions 6 and 7 embed a timestamp at the front so generated values sort chronologically. They keep UUID uniqueness while behaving more like sequential IDs for indexing — the best of both worlds for databases.

UUIDs in distributed ID systems

Systems like Snowflake generate time-ordered, node-aware IDs that avoid coordination while staying sortable. UUID v7 borrows the same idea in standard form. If you need both uniqueness and chronological order across services, these are worth knowing.

Testing UUID uniqueness

In tests, generate a few thousand and check for duplicates to confirm your generator isn't secretly sequential or seeded. For v4, you should never see a repeat; for time-ordered variants, ordering should be monotonic.

When a short ID is enough

For public, user-facing slugs, a random 8-character ID is often preferable to a full UUID: shorter, shareable, and still unguessable enough. Reserve full UUIDs for internal keys where uniqueness is paramount.

UUIDs in test fixtures

Tests need stable, unique IDs. Generate them once and freeze them as fixtures rather than calling a random generator per run — that way failures are reproducible and logs reference the same IDs each time. A UUID generator is handy for seeding those fixtures initially.

Try the UUID Generator →