UUID Generator (v4 and v7)
Generate one UUID or five hundred, as random version 4 or time-ordered version 7, formatted however your target system wants them. They come from your browser's own cryptographic random number generator, which means nobody else has ever seen them — including us, because there is no request to a server that could have handed the same value to somebody else.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeWhat it does
- Version 4 random and version 7 time-ordered identifiers
- Up to 500 at once
- Uppercase, hyphen-free, and brace-wrapped output
- Uses crypto.getRandomValues, not Math.random
How to use UUID Generator
- 1
Pick a version
Version 4 is the familiar random one and the right default. Version 7 puts a millisecond timestamp in front, so the values sort chronologically — the choice that matters if they are going to be database primary keys.
- 2
Choose how many
Anything from one to five hundred. Bulk generation is for seeding a test database or a fixtures file, where you want a stable set to paste in one go.
- 3
Set the format
Hyphens on is canonical. Turn them off for systems that store the raw 32 hex digits, and turn braces on for Microsoft tooling, which writes GUIDs wrapped in curly braces.
- 4
Copy the block
Copy takes every generated value at once, one per line. Press Generate again for a completely new set — nothing is remembered between runs.
How it works
A UUID is 128 bits with two small regions reserved. Everything else is either random or a timestamp, depending on the version.
For version 4, sixteen random bytes are drawn from crypto.getRandomValues.
Then two of them are partially overwritten: the high nibble of byte 6 is set to
0100 to mark the version, and the top two bits of byte 8 are set to 10 to
mark the variant. That is six bits spent on identification, leaving 122 random —
and it is why every version 4 UUID you have ever seen has a 4 as its
thirteenth hex digit.
For version 7, the first six bytes are the current time in milliseconds since 1970, written big-endian. The remaining ten bytes are random, and the same version and variant fields are stamped over the top of them.
One detail in that timestamp is easy to get wrong. Forty-eight bits does not fit in a JavaScript bitwise operation, which truncates to 32 — so writing the timestamp with shifts silently produces UUIDs whose first two bytes are always zero, and they still look completely normal. Building the value a byte at a time with division avoids the problem entirely.
Why not crypto.randomUUID
The browser has a built-in crypto.randomUUID() that does exactly what the
version 4 path here does. It is not used, for one specific reason: it is only
defined in a secure context. On a plain-http local development server it is
undefined, so a tool built on it appears to be broken on the first machine
anyone would try it on. Six lines of getRandomValues works in every context,
and it also makes the version and variant bits visible in the source rather than
hidden inside a native call.
When you'd use this
Seeding a test database with a stable set of keys. Filling in a fixture file. Producing an idempotency key for an API request. Naming a resource that has to be unique across systems that never talk to each other — which is the original problem UUIDs were invented for, and still the one they are best at.
The case against UUIDs as primary keys
Worth knowing before you commit a schema to them.
A random UUID is 16 bytes against an integer's 4 or 8, and every secondary index carries a copy of the primary key, so the cost multiplies. More importantly, a random key inserts into a random position in the index, which on a large table means constantly writing to pages that are not in memory and splitting them when they fill.
Version 7 exists precisely because of that, and it is why the recommendation above is not "use v4 for everything". If the identifiers are going into a table that will get large, the time-ordered form gives you the global uniqueness of a UUID with the insert behavior of an auto-incrementing integer. The price is that the creation time is public, which is a real trade rather than a free upgrade.
Examples
The fixed bits in a version 4 UUID
Even with every single random byte forced to its maximum, two positions cannot be all-ones: the 13th hex digit is always 4 and the 17th is always 8, 9, a or b. Those are the version and variant fields overwriting six of the random bits, which is why a v4 UUID carries 122 bits of randomness rather than 128.
The timestamp visible in a version 7 UUID
The first twelve hex digits, 019b76daa800, are the creation time in milliseconds since 1970 written as a 48-bit big-endian integer. That is what makes v7 values sort chronologically as plain strings — and also what makes them unsuitable for anything that must not reveal when it was created.
Frequently asked questions
Are these UUIDs actually random, or generated from a seed?
They come from crypto.getRandomValues, which is your browser's cryptographically secure generator, not Math.random. That distinction is real: Math.random is seeded predictably and its output can be reconstructed from a handful of previous values, which has been demonstrated repeatedly against sites that used it for tokens. Nothing here is seeded by us and no value is ever sent anywhere.
Should I use version 4 or version 7?
Use v7 for database primary keys and v4 for everything else. A v7 value sorts by creation time, so inserts append to the end of the index instead of scattering across it — on a large table that is the difference between a compact index and a fragmented one. Use v4 whenever the identifier is exposed publicly or must not disclose timing, because a v7 tells anyone holding it exactly when it was created.
Can two UUIDs ever collide?
In principle yes, in practice no, and the number is worth internalising once. With 122 random bits you would need to generate about 2.7 quintillion version 4 UUIDs before there was a one-in-a-billion chance of any two matching. Generating a billion per second, that is over eighty years. The realistic collision risk is a broken random source, not the mathematics — which is why the generator used here matters more than the version does.
Why do some systems want the hyphens removed?
Because the hyphens carry no information. A UUID is 128 bits, written as 32 hex digits, and the 8-4-4-4-12 grouping is purely a display convention from the original specification. Databases that store the value as 16 raw bytes or as a CHAR(32) have no use for them, and some APIs reject them. The value is identical either way, so removing them is safe.
Is a GUID the same thing as a UUID?
Effectively yes. GUID is Microsoft's name for the same 128-bit identifier and the same specification, and the two terms are interchangeable in practice. The visible difference is convention: Microsoft tooling traditionally writes them wrapped in curly braces and often in uppercase, which is why both of those are options here.