UUID Generator — Bulk v4 UUIDs, Cryptographically Random

Why you can just generate and not check

A v4 UUID has 122 random bits — the odds of a collision between two generated IDs are so low that 'generate and check for uniqueness' is actively wrong engineering. You'd need ~2.7×10¹⁸ UUIDs for a 50% collision chance; your database will run out of disk first. This is why UUIDs replaced sequences for distributed IDs.

The practical caveat: UUIDs make lousy primary keys in B-tree indexes because random inserts fragment the index. UUIDv7 (time-ordered, new in RFC 9562) fixes this — use it where insert order matters.

v4 vs v7 — which UUID version

v4 (what this generates) is pure randomness — the right choice for most uses, universally supported. v7 embeds a millisecond timestamp in the first bits, making UUIDs sortable and index-friendly; it's the modern default for database keys. v1 (time+MAC) and v3/v5 (hash-based) are legacy — never use v1, it leaks your MAC address.

Frequently asked questions

Are these UUIDs safe to use?

Yes — they're generated by crypto.randomUUID(), a cryptographically secure random source, not Math.random(). Suitable for session IDs, tokens and database keys.

Can two UUIDs ever collide?

Mathematically possible, practically impossible — ~122 bits of randomness means you'd need quintillions of UUIDs before a collision becomes likely. Don't check for uniqueness; it's a waste.

UUID vs GUID — what's the difference?

Nothing — GUID is Microsoft's name for the same RFC 4122/9562 identifier format. Same structure, different branding.

Should I use UUIDs as database primary keys?

v4 UUIDs work but fragment B-tree indexes due to random inserts. UUIDv7 (time-ordered) is the better modern choice for PKs — this generator produces v4.