≣UUID Generator

Version 4 UUIDs, generated in bulk, formatted however the system you are pasting into expects them.

The options exist because platforms disagree. Microsoft tooling tends to want braces. Some databases store them stripped of hyphens to save four bytes. Plenty of APIs reject anything that is not lowercase. None of it changes the identifier, only its presentation.

Why version 4 rather than version 1

Version 1 embeds a timestamp and the network card address of the machine that created it. That is a privacy problem and an infrastructure disclosure, and it is the reason version 4 — which is essentially all random — became the default choice for anything public-facing.

Random also means machines can generate them independently without coordinating, which is the property that makes UUIDs useful in the first place.

The collision question

A version 4 UUID carries 122 random bits. Collisions are not impossible in theory and people occasionally write defensive code for them, which is close to wasted effort: you would need to generate billions per second for years before the probability became worth a line of code. Plan around them not happening.

Where they are the wrong choice

As a clustered primary key at scale, random UUIDs scatter writes across the index and hurt insert performance measurably. If that matters, a time-ordered scheme such as UUIDv7 or ULID keeps the uniqueness while restoring locality.

And an unguessable URL is not access control. 122 bits cannot be enumerated, but the URL still leaks through browser history, referrer headers, and the moment someone pastes it into a group chat.

Generation uses crypto.randomUUID where the browser provides it, falling back to crypto.getRandomValues with the version and variant bits set correctly. Both are cryptographic sources, which is not true of every UUID library you will encounter.