UUID Generator

UUID v4 is 122 random bits with 6 bits of fixed version/variant metadata. Collisions are astronomically improbable but the IDs have no temporal order — inserting them as a primary key into a B-tree index causes random I/O across the entire tree, which slows down write-heavy workloads on tables with many millions of rows.

UUID v7 (RFC 9562, 2024) fixes this by prefixing 48 bits of millisecond Unix timestamp before 74 bits of randomness. Sorting v7 UUIDs by their string value yields rough chronological order, which means new rows insert into the rightmost leaf of a B-tree — the same access pattern as auto-increment integers, without the coordination problem.

• v4 — default for client-side IDs, opaque identifiers, share links. Never sorts, but you do not care because the UUID is not your primary key.
• v7 — default for database primary keys when you cannot use auto-increment integers (distributed systems, multi-master replication, sharded tables). Indexes behave like sequential inserts.
• v1 — historical, leaks the MAC address of the generator and a timestamp. Useful for forensics, useless for everything else. Avoid unless you have a specific reason.
• v6 — re-ordered v1 that sorts correctly. Superseded by v7 in practice; only use if you need MAC-address linkage AND sortability simultaneously, which is rare.
• v3, v5 — namespace-based (hash a name within a namespace). Use these when you want the same input to always yield the same UUID (deterministic IDs from URLs, for instance).

• You need a one-off test ID and your project does not have a generator imported yet.
• You are evaluating whether to migrate from v4 to v7 for primary keys and want to inspect the bit layout before committing.
• You are filling a fixtures file with 50 sample IDs and want them to look realistic without writing a script.
• You are debugging a UUID parsing issue and need to confirm the variant/version nibbles are what you expect.

• It will not generate ULIDs, KSUIDs, NanoIDs, or other competing schemes. UUID v7 covers most use cases those were designed for. If you specifically need a 26-character Crockford base32 string (ULID) for URL aesthetics, use a dedicated tool.
• It will not coordinate with your database. UUIDs are unique by probability, not by uniqueness check — collisions across 100 billion generated v4 UUIDs have probability around 10^-18.
• It will not check your existing data for collisions. For a one-off audit, just SELECT id, COUNT(*) FROM your_table GROUP BY id HAVING COUNT(*) > 1.