UUID / GUID Generator
Generate RFC 9562 version 4 and version 7 UUIDs in bulk, or decode an existing one to see its version, variant and embedded timestamp.
Decode an existing UUID
Paste any UUID to read its version, variant and — for time-based versions — the instant it was created.
| Decoded | Paste a UUID above, then press Decode. |
Which version should you use?
| Version | Built from | Sortable? | Use it when |
|---|---|---|---|
| v4 | 122 random bits | No | The safe default. No information leaks, no coordination needed. |
| v7 | 48-bit millisecond timestamp + 12-bit counter + 62 random bits | Yes | Database primary keys. Time-ordered, so index inserts stay sequential. |
| v1 | Timestamp + MAC address | Roughly | Legacy only. It leaks the generating machine's MAC address and creation time. |
| v5 | SHA-1 of a namespace and a name | No | You need the same input to always produce the same UUID. |
Why v7 matters for databases
This is the part most people miss. If your primary key is a random UUID and the database indexes it with a B-tree, every insert lands at a random position in the index. That causes page splits, fragmented indexes and a write pattern that is dramatically slower at scale than sequential inserts — an effect often called index locality or write amplification.
UUIDv7 puts a millisecond timestamp in the leading 48 bits. Values generated a moment apart are therefore adjacent, so inserts append near the end of the index instead of scattering. You keep the global uniqueness of a UUID and recover most of the write performance of an auto-increment integer.
One detail is easy to miss. A timestamp with millisecond resolution only orders values created in
different milliseconds — a service inserting thousands of rows per second generates
plenty inside the same one, and if the remaining bits are random those rows still land in random
index positions. This generator fills the 12-bit rand_a field with a counter that
increments within each millisecond, as RFC 9562 section 6.1 describes, so values are strictly
ascending even under bursts. Many generators skip this and ship v7 that is only
loosely time-ordered.
Are UUIDs actually unique?
Version 4 has 122 random bits. By the birthday bound, you would need to generate roughly 261 — about 2.3 quintillion — UUIDs before the chance of any single collision reaches 50%. To put that in perspective: generating one billion UUIDs per second, it would take about 73 years to reach even a 1-in-a-billion chance of a duplicate.
The real risk is never the maths. It is a broken random source — a container with a bad entropy
pool, a seeded PRNG, or Math.random(), which is not cryptographically secure and
should never be used here. This generator uses crypto.getRandomValues(), the
operating system's CSPRNG.
Do not use UUIDs as security tokens. They are unique, not unpredictable in a security sense once an attacker controls the generator, and they are often logged, cached and exposed in URLs. Use a proper secret for anything that grants access.
Frequently asked questions
What is the difference between a UUID and a GUID?
Nothing meaningful. GUID is Microsoft's name for the same concept. The string formats and the underlying 128-bit values are compatible.
Should I store UUIDs as text or as a 128-bit binary?
If your database has a native UUID type, use it. Otherwise prefer binary(16): a UUID stored as a 36-character string triples the index size and slows comparisons.
Can I use v7 everywhere instead of v4?
Almost everywhere, yes. The one caveat is that v7 reveals creation time to anyone who can read the ID. If creation time is sensitive, stay on v4.
Why do some UUIDs start with 00000000 or ffffffff?
Those are the nil UUID and the max UUID, reserved values used as sentinels. The decoder flags both.
Privacy. Generation uses your browser's cryptographic random number generator. Nothing is uploaded, requested or logged.