UUID generator

Identifiers, not secrets

I generate UUIDs here when a seed script, a local database, or a demo invoice needs unique keys that will not collide with last week’s fixtures. I do not generate them here to use as session tokens, password-reset secrets, or API keys. A v4 UUID is an identifier. Knowing one should not grant access. If your authorization check is “the client presented a UUID we issued,” that is a capability URL with a guessable-enough surface once logs, screenshots, and support tickets exist.

This page fills the RFC 4122 layout: 8-4-4-4-12 hex, version nibble 4 for v4, variant bits in the RFC range. Randomness comes from Math.random, not crypto.randomUUID(). That is enough for test data and most client-side IDs. It is the wrong generator if a threat model says “an attacker who can predict Math.random wins.” For production primary keys I still prefer v4 from a CSPRNG in the app, or a database gen_random_uuid(). The v1 option here is a simplified timestamp-ish string, not a full MAC-address RFC 4122 v1. Do not treat it as sortable time proof and do not assume it embeds a real NIC.

Worked example: five fixture rows

Set version to v4, count to 5, leave uppercase off. You get five lowercase strings such as the shape 3f6d8a12-9c4e-4b21-a8d0-7e1c2b9f04aa — third group starts with 4, fourth group starts with 8, 9, a, or b. Paste them into an INSERT for a local Postgres. If you generate 5, copy 4, and type the fifth from memory, you will duplicate one. Copy-paste duplicates beat theoretical collisions at this volume by a ridiculous margin.

Worked example: uppercase vs the RFC

Canonical form is lowercase. Many .NET and older Java libraries emit uppercase. Both parse. Mixing them in a string-keyed map does not: 3F6D8A12-... and 3f6d8a12-... are different keys in a JS object. Indian GST portals and some bank APIs are case-sensitive on their own identifiers; UUIDs you send as correlationId should pick one case and keep it. I keep lowercase unless a vendor sample is uppercase.

Worked example: collision math vs operational bugs

Birthday-paradox talk for v4 at millions of rows is a fun Slack thread. In a 50-row seed file, the failure I actually see is generating once, copying the list, generating again, and merging both lists into the same table with a unique constraint. Second generate is a new set; you did not “refresh” the first set. Count is capped at 100 here so the DOM does not eat a million nodes. Need 10,000 IDs? Write a ten-line script. Need monotonically increasing IDs for pagination? UUID v4 will not sort by creation time. Use an identity column, a ULID, or a KSUID — not this page’s v1 sketch.

What not to do with the hex

Do not truncate to 8 characters and call it unique. Do not use a UUID as a password. Do not put a sequential integer in the “random” bits by hand. Do not parse v1 here as if it were a timestamp you can convert with the timestamp tool — it is not a faithful v1. Nil UUID 00000000-0000-0000-0000-000000000000 is a sentinel some libraries reserve; this generator will not emit it on purpose, but you can still type it into a form and confuse a unique index.

Questions

Related tools

JWT decoderHash generatorJSON formatterPassword generator