v4 or v7 — which do I want?

If it is a database primary key, v7. If it must be impossible to guess — a password reset link, an invite code, a session identifier — v4. That is the whole decision, and most people never learn there was one, because almost every generator offers only v4.

Why is v4 bad as a database key?

Because it is completely random, and a database index is sorted. New random keys land in random places in the index, so every insert touches a different page, the cache stops helping, and the index fragments and grows. On a large busy table this is a measurable slowdown that gets worse over time. It is not a theoretical concern — it is the reason Postgres and MySQL documentation now both discuss it.

A UUID whose first 48 bits are a millisecond timestamp, followed by randomness. It is still globally unique and still 128 bits, but because the time comes first, v7 UUIDs sort in the order they were created. New keys append to the end of the index instead of scattering through it, which is exactly how an auto-incrementing integer behaves — with the uniqueness of a UUID. It was standardised in RFC 9562 in 2024 and it is the current recommendation for new tables.

Do the v7 UUIDs here actually sort?

Yes, including within the same millisecond, which is the part most implementations get wrong. A timestamp only has millisecond resolution, so generating a thousand IDs in a loop finishes inside one — and with purely random low bits those thousand do NOT sort into the order they were made. This generator uses the monotonic counter described in RFC 9562, so a batch is strictly ascending, every time. Generate a thousand and sort them; they come back in the order they were created.

Is a v7 UUID safe to expose publicly?

With one thing in mind: it reveals when it was created, to the millisecond, by design. For a database key that is usually harmless or even useful. But if the creation time is itself sensitive, or if you need the identifier to be unguessable, use v4 — v7 still has 74 random bits, which is a great deal, but its timestamp is plainly readable by anyone who has the ID.

Are these random enough to be secure?

Yes. Randomness comes from `crypto.getRandomValues`, the browser's cryptographically secure generator, never from `Math.random`. That distinction has caused real vulnerabilities: `Math.random` is fast but predictable, and session tokens built on it have been guessed in practice. A v4 UUID has 122 random bits, which is enough that collisions are not a practical concern.

Are they generated on my device?

Yes, entirely, and for identifiers that matters. A UUID fetched from someone else's server is a UUID that someone else has seen — which defeats the purpose if you are generating a secret. These never leave your browser. Yes. Once the page has loaded, turn off your Wi-Fi and it works exactly the same. That is the simplest way to confirm the privacy claim for yourself rather than taking our word for it — and with the developer tools open on the Network tab, you can watch that nothing is sent.

What is the nil UUID?

All zeroes: 00000000-0000-0000-0000-000000000000. It is a valid, reserved UUID used to mean "none" or "not set" where a null is not possible. Its opposite, the max UUID of all fs, is sometimes used as a sort sentinel. Both are offered here because they are occasionally needed and awkward to type correctly.

Generate UUIDs

Processed on your device — nothing is uploaded

Which version?

How many

Format

Your 0 UUIDs

Have a UUID already? Find out what it is