What a UUID is, and what v4 promises
A UUID (universally unique identifier) is a 128-bit value written as 32 hexadecimal digits in five groups — 8-4-4-4-12 — for a total of 36 characters including the hyphens. The idea, dating to the 1980s and standardised as RFC 4122 (now RFC 9562), is radical in its simplicity: any computer, anywhere, can mint a new identifier without asking a central authority, and the identifier will — with overwhelming probability — never be minted again by anyone else. Version 4 is the purely random flavour: of the 128 bits, 122 come straight from a random number generator, and the remaining 6 are fixed markers that announce "this is a variant-1, version-4 UUID". You can spot them in the wild by those markers: the third group always starts with 4, and the fourth group always starts with 8, 9, a or b. Everything else is chance.
How to use this generator
- Choose how many you need — one for a quick test fixture, or a batch of up to 100 for seeding a table or a test run.
- Set the format first. Lowercase with hyphens is the canonical form most systems expect; tick UPPERCASE or untick Hyphens only when the receiving system asks for it.
- Press Generate UUIDs. Every press is a fresh batch from the browser's cryptographic random source — pressing it twice never repeats a list.
- Copy what you need: the button on each row takes that single UUID, and Copy all takes the whole batch, one per line, ready to paste into code, SQL or a seed file.
Where the randomness comes from
A UUID generator is only as good as its entropy, so this page is
explicit about its source: it calls
crypto.getRandomValues, the browser's interface to the
operating system's cryptographically secure random generator — the
same source used to mint the keys that protect TLS connections. It
never uses Math.random, which is a fast, predictable
PRNG designed for games and shuffling playlists: its future outputs
can be reconstructed from a few observed ones, which for
identifiers that double as unguessable tokens (password-reset
links, API keys, session IDs) is a real vulnerability, not a
theoretical one. If a generator does not tell you where its
randomness comes from, assume the answer is the bad one.
UUIDs in practice
The places you will meet v4 UUIDs: primary keys in distributed databases, where several servers insert rows without coordinating; object-storage and file names, where the name itself must not collide or leak how many files exist; idempotency keys on payment and API requests, where a retried request must be recognisable as the same request; and correlation IDs sprinkled through logs so one user action can be traced across five services. Two practical notes from the field. First, store them as 16-byte binary (or a native UUID type) rather than 36-character text when your database offers it — half the index size, and comparisons get faster. Second, a v4 UUID in a URL is unguessable but it is not an access control: anyone you show the link to has the ID, so check permissions on the server anyway. Unguessable means strangers cannot enumerate your records; it does not mean the bearer of the link is authorised.