UUID Generator
Version 4 and version 7 UUIDs in bulk, plus a decoder for one you already have.
Version 7 sorts chronologically, which matters for a database key.
How it works
A version 4 UUID is 122 random bits with six bits spent on version and variant markers. There is no coordination, no central authority and no collision check — it works purely because 2¹²² is an unimaginably large number. To reach a 50% chance of a single collision you would need to generate about 2.7×10¹⁸ of them; at a million per second that is roughly 85,000 years.
That randomness has a cost that only shows up at scale, and it is a database cost. Random identifiers arrive in no particular order, so inserting them into a B-tree index writes to a random page every time. The index does not stay in cache, pages split constantly, and the table fragments. On a large table the difference against a sequential key is not subtle.
Version 7 fixes exactly this. The first 48 bits are a Unix timestamp in milliseconds, followed by random bits, so identifiers generated later sort after identifiers generated earlier while remaining effectively unguessable. Inserts land at the end of the index, and the recent pages — the ones actually being read — stay in memory. If you are choosing a primary key today and want a UUID, version 7 is the one to choose.
The trade is that a v7 UUID leaks its creation time to anyone who has it. That is usually harmless and occasionally not: it means an identifier in a URL reveals when the record was made, and a sequence of them reveals your creation rate.
Version 1 — still common in older systems — went further and embedded the machine's MAC address, which is why it fell out of favour. This tool reads the timestamp out of v1 and v7 UUIDs when you paste one in.
Common questions
Version 4 or version 7?
Version 7 for anything that becomes a database key, because it sorts by creation time and keeps index inserts sequential. Version 4 where the identifier is public and you would rather it revealed nothing at all, including when it was made.
Could two UUIDs ever collide?
In principle. In practice, reaching even a 50% chance of one collision takes on the order of 10¹⁸ UUIDs. The realistic risk is not the mathematics but a broken random source — which is why these use the browser's cryptographic generator rather than Math.random.
Are they safe to use as a secret?
A v4 UUID has 122 bits of entropy, which is plenty. But they end up in logs, in URLs, in analytics and in referrer headers, because nobody treats an identifier as a secret. Use a token you can revoke instead.
Why does my UUID have a 4 in the same place every time?
That digit is the version field, not data — every version 4 UUID has it. The first digit of the fourth group is the variant and is always 8, 9, a or b. Those six bits are the difference between 128 bits and the 122 that are actually random.