Are these UUIDs safe to use?

Yes. They come from crypto.getRandomValues, the browser's cryptographic random number generator, never from Math.random. Math.random is predictable from previous output and has caused real-world id collisions.

Will two UUIDs ever collide?

A v4 UUID has 122 random bits. You would need to generate about 2.7 quintillion of them before a 50 percent chance of a single collision. For any normal application the risk is not worth planning around.

What is UUID v7 and why would I use it?

v7 puts a 48-bit Unix millisecond timestamp at the front, so the ids sort chronologically as plain strings. That makes them far better database primary keys than v4, whose randomness scatters inserts across the whole index and fragments it.

Should I use a UUID as a database primary key?

You can, but prefer v7 over v4. Random keys cause page splits and index fragmentation on every insert. A time-ordered key appends to the end of the index like an auto-increment integer while staying globally unique.

A v4 UUID is unguessable enough to act as a capability URL, but it is not a substitute for authentication. Anything derived from a timestamp, including v1 and v7, reveals when it was created - and v1 also leaks the generating machine's MAC address.

Are the ids generated on your server?

No. They are generated in your browser and never transmitted, so nobody else has ever seen them.

Unique → identifiers

Random v4 or time-ordered v7, one at a time or a thousand at once, formatted the way your language expects. Generated with the browser's cryptographic random source — never Math.random — and never transmitted.

Versions: v4 random · v7 time-ordered
Entropy: 122 bits · crypto grade
Bulk: up to 1,000

Step 1

Generate

never leaves this page

Version

How many

Which version?
Pick v4 when the id is public and must reveal nothing — a password-reset link, a share token, an external reference. Pick v7 when it will be a database key: the timestamp at the front keeps inserts at the end of the index instead of scattering them.

Both are RFC 4122 compliant and both carry 122 bits of randomness, so collision risk is identical in practice.

Inspect any UUID

Step 2

Your identifiers

Format

empty

—

Nothing generated yet Choose a version and press Generate.

v4 or v7?

v4 — random

122 random bits

Reveals nothing: not when it was made, not by which machine, not how many came before it. The right choice for anything a stranger will see — reset links, share tokens, public references. As a database key it is the worst case, because every insert lands in a random spot in the index.

v7 — time-ordered

48-bit timestamp + random

Sorts chronologically as a plain string, so rows insert at the end of the index like an auto-increment integer while staying globally unique. The trade-off is that it tells anyone holding it roughly when the record was created.

Worth knowing

Collisions are not a real concern

With 122 random bits you would need roughly 2.7 quintillion ids before reaching a 50% chance of one collision. Generating a million a second, that is longer than most companies exist. Do not write reconciliation code for it.

Math.random is not good enough

It is a fast pseudo-random generator, not a cryptographic one: its future output is derivable from past output. Ids built on it have been guessed in the wild. Everything here uses crypto.getRandomValues.

Random keys fragment indexes

A B-tree keyed on v4 takes an insert in a random leaf every time, causing page splits and poor cache locality. On a large, write-heavy table this is measurable. v7, or a separate sequential key, avoids it.

Store them as bytes, not strings

A UUID is 16 bytes. Stored as char(36) it is 36, plus index overhead on every row. Use uniqueidentifier, uuid or binary(16) if your database offers it.

Unguessable is not authenticated

A v4 in a URL is fine as a capability — hard to guess, easy to revoke. It is still not authentication: URLs leak through browser history, referrer headers, chat previews and server logs.

v1 leaks your hardware

Version 1 embeds a timestamp and the generating machine's MAC address. That is genuine information disclosure and it is why v1 has fallen out of use. Prefer v4 or v7.

The versions in full

Version	Built from	Use it when
`v1`	Timestamp + MAC address	Legacy only. Leaks hardware identity and creation time.
`v3`	MD5 of a namespace + name	You need the same input to always produce the same id. Prefer v5.
`v4`	122 random bits	Default choice. Public ids, tokens, anything that must reveal nothing.
`v5`	SHA-1 of a namespace + name	Deterministic ids derived from stable names, such as a URL or DNS entry.
`v7`	Unix milliseconds + random	Database primary keys, event ids, anything you want sorted by creation time.

Other tools

JWT DecoderWhere a jti claim ends up. Base64 EncoderShorten an id for a URL. URL EncoderPut an id in a query string. JSON FormatterInspect a payload full of ids.