UUID Generator — Bulk v4 UUIDs

Random UUIDs are safe to generate independently but poor as a primary key

The reason is database internals rather than anything wrong with the UUID. A random identifier has no ordering, so rows arrive at arbitrary positions in a B-tree index instead of appending at the end. Inserts scatter writes across the whole index rather than concentrating them, which causes page splits and poor cache locality. A sequential integer or a time-ordered key appends, and appending is dramatically cheaper.

The size cost multiplies across the schema

A UUID is 16 bytes stored binary, against 4 or 8 for an integer — so two to four times the size. That would be minor on its own, except the primary key is duplicated into every secondary index, so the overhead compounds across the table rather than being paid once.

Stored or transported as a 36-character string it grows again, to more than double the binary size. Worth checking how your database actually stores it, because the difference between a native UUID type and a text column is substantial and easy to get wrong by accident.

What this tool generates

Version 4 UUIDs, using crypto.randomUUID() where available and falling back to crypto.getRandomValues() — both cryptographically secure sources rather than Math.random(). It produces 1 to 100 per batch, with an uppercase toggle and copy buttons for individual values or the whole set.

Version 4 fixes a handful of bits to mark the version and variant, leaving 122 random bits rather than the full 128. That is still an enormous space, and collisions are not a practical concern at any realistic volume — which is exactly the property that makes UUIDs useful. Two systems that have never communicated can each mint identifiers with no coordination at all, which is why they suit identifiers created offline, on a client, or across independent services.

Modern alternatives restore sortability

Time-ordered identifiers such as UUID version 7 and ULID were designed to keep decentralised generation while making inserts append rather than scatter — they put a timestamp in the high bits so values sort roughly by creation time. This tool generates version 4 only, so if you need ordered identifiers you will need a different generator.

One further point in favour of random UUIDs, and it is a real one: they leak nothing. A sequential integer in a URL lets anyone enumerate your records and estimate your total volume, which is why a common and sensible pattern is to expose UUIDs publicly while keeping sequential integers as the internal key — you get the index behaviour of an integer and the opacity of a UUID.

A practical note on comparison: hex casing varies between systems, so compare case-insensitively, and treat the hyphens as presentational rather than part of the value.

A UUID identifies something without revealing anything about it, which is a different job from protecting access to it. For that, the password generator is the right tool.