What is the difference between UUID v1, v4, and v7?

v1 embeds a timestamp and MAC-derived node bits—globally unique but leaks timing and hardware fingerprints unless privacy extensions are used. v4 is random except for version/variant bits—no ordering, excellent unpredictability. v7 combines Unix ms timestamp in the high bits with randomness—sortable by creation time while retaining large random space.

How likely is a UUID collision?

For v4, treat 122 random bits as a birthday problem: collision probability stays negligible until you generate astronomical counts. Practical collisions almost always come from bugs—bad RNG seeding, duplicated VMs, or copy-paste errors—not from math at normal scales.

UUID vs auto-increment primary keys?

Auto-increment is compact and index-friendly but exposes row order and complicates sharded writes. UUIDs distribute inserts across B-tree pages but historically caused fragmentation; v7 restores locality for clustered indexes. Choose based on exposure, sharding, and ORM defaults—not fashion.

How should UUIDs be stored in databases?

Use native UUID types where available; avoid VARCHAR if the engine has a 16-byte binary form. For MySQL with clustered PKs, prefer v7 (or ordered binary) to reduce page splits. Index secondary tables on the columns you actually query—UUID primary keys still need thoughtful foreign-key strategy.

ULID vs UUID—when does ULID win?

ULIDs are 128-bit Crockford base32 strings with timestamp-first lexicographic order and a smaller canonical text size than hyphenated UUIDs. UUID v7 now covers similar sortability inside the RFC UUID space. Pick based on ecosystem support, human readability, and library maturity in your stack.

UUID Generator

v1.0.0

Generate UUID v4, and v7, with bulk generation, copy tools, history, case toggle, and secure randomness.

Count:

UUID v4: Random UUID using cryptographically secure random numbers

Click Generate to create UUIDs

Produce RFC-compliant UUIDs in the version your architecture needs—random v4 for opacity, v7 for time-friendly indexing. Copy standard hyphenated strings ready for JSON and SQL.

Read the full guide →

Frequently Asked Questions

What is the difference between UUID v1, v4, and v7?: v1 embeds a timestamp and MAC-derived node bits—globally unique but leaks timing and hardware fingerprints unless privacy extensions are used. v4 is random except for version/variant bits—no ordering, excellent unpredictability. v7 combines Unix ms timestamp in the high bits with randomness—sortable by creation time while retaining large random space.
How likely is a UUID collision?: For v4, treat 122 random bits as a birthday problem: collision probability stays negligible until you generate astronomical counts. Practical collisions almost always come from bugs—bad RNG seeding, duplicated VMs, or copy-paste errors—not from math at normal scales.
UUID vs auto-increment primary keys?: Auto-increment is compact and index-friendly but exposes row order and complicates sharded writes. UUIDs distribute inserts across B-tree pages but historically caused fragmentation; v7 restores locality for clustered indexes. Choose based on exposure, sharding, and ORM defaults—not fashion.
How should UUIDs be stored in databases?: Use native UUID types where available; avoid VARCHAR if the engine has a 16-byte binary form. For MySQL with clustered PKs, prefer v7 (or ordered binary) to reduce page splits. Index secondary tables on the columns you actually query—UUID primary keys still need thoughtful foreign-key strategy.
ULID vs UUID—when does ULID win?: ULIDs are 128-bit Crockford base32 strings with timestamp-first lexicographic order and a smaller canonical text size than hyphenated UUIDs. UUID v7 now covers similar sortability inside the RFC UUID space. Pick based on ecosystem support, human readability, and library maturity in your stack.