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 | v4, v7 & GUID Online

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.

Try it now: Open the free UUID Generator | v4, v7 & GUID Online tool — no sign-up required.

What the UUID format encodes

A canonical UUID is 128 bits, written as eight-four-four-four-twelve hexadecimal digits. Fixed version nibbles mark the generating algorithm (e.g., 4 for random, 7 for Unix timestamp plus random). Variant bits distinguish RFC layout from legacy Microsoft/NCS formats. That structure lets parsers validate quickly and databases store compactly. Treat the string as opaque in application logic—parsing internals belongs in infrastructure code, not business rules.

Picking a version with intent

Use v4 when you need unpredictable identifiers for public tokens, upload keys, or correlation IDs where order must not leak business activity. Use v7 when insert-heavy tables benefit from monotonic primary keys—think multi-tenant SaaS event tables—without reverting to leaky v1 timestamps. Avoid v1 on externally visible IDs unless you have scrubbed node bits; MAC-derived data is a footgun on privacy reviews. When you need shorter printable tokens unrelated to the UUID spec, pair this tool with a random string generator instead of truncating UUIDs.

Databases, replication, and sharding

UUID primary keys simplify merging shards and offline clients: no central sequence coordinator. The tradeoff was random v4 insert patterns causing B-tree hotspots; v7 restores time locality while preserving distributed generation. Still add secondary indexes thoughtfully—wide tables with many UUID FKs can bloat if every column is indexed by default. For credentials derived from random material, do not confuse UUIDs with passwords; use a password generator for human-facing secrets and store hashes produced with proper KDFs—our hash generator is illustrative for checksums, not credential storage.

Interop and string hygiene

JSON APIs should emit lowercase hex; some databases normalize case on insert, others do not—pick one convention per service. When logging, prefer structured fields over regex-parsing strings. For testing, generate batches here, then freeze fixtures in VCS so CI stays deterministic. In production, generate inside your runtime’s crypto-safe APIs to keep RNG quality under your control—the online tool is for design-time and debugging, not high-rate issuance at scale.

Migration, exposure, and when UUIDs are not secrets

Greenfield services should prefer v7 for time-ordered clustering when the storage layer benefits; stick with v4 when you need maximum opacity and index locality is solved elsewhere. Migrating live tables from v4 to v7 is usually a new column plus backfill story, not an in-place rewrite of primary keys, because foreign keys and cached URLs depend on stable IDs. If you expose UUIDs in public URLs, treat them as capabilities: use v4 randomness or signed tokens instead of predictable sequences. When systems also emit short codes, generate those separately with a random string tool and enforce uniqueness in the database—do not truncate UUIDs and hope for the best. UUIDs are identifiers, not secrets: v4 values resist guessing at scale, but you still need authentication and authorization around any resource located by ID. v1 and some v6 layouts leak timing information; avoid them in customer-visible contexts unless you have audited the privacy implications. For password-reset or invitation tokens, prefer dedicated high-entropy secrets from a password generator or crypto APIs with explicit expiry, not UUIDs chosen for convenience. When correlating logs across services, UUID trace IDs are fine; pairing them with a hash generator output of a stable seed is not a substitute for proper request signing.

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.

Ready to try it yourself?

Use UUID Generator | v4, v7 & GUID Online for Free