Should I use UUID v4 or v7?

v7 if the UUID will be a database primary key. It starts with a millisecond timestamp, so values generated over time sort together and insert into a B-tree index without fragmenting it. v4 is fully random, which is the right choice when the identifier should reveal nothing about when it was created.

Are these UUIDs random enough to be unguessable?

Yes. They come from the browser's crypto.getRandomValues(), which is a cryptographically secure source. A v4 UUID has 122 random bits. Note that a v7 UUID deliberately encodes its creation time, so it is unguessable but not opaque.

Can two generated UUIDs collide?

Not in practice. You would need to generate about 2.7 × 10^18 v4 UUIDs before a collision becomes as likely as not. The realistic risk is a broken random source, not the maths.

UUID Generator

Generate UUIDs locally from your browser's cryptographic random source.

Version 4 UUIDs

0 generated

Options

Count

Uppercase

Hyphens

Braces

Processed locally in your browser. Values come from your browser's CSPRNG and are never transmitted. Reload the page and they are gone.

Reference

Where these come from

Values are generated by crypto.getRandomValues(), your browser's cryptographically secure random source. Nothing is fetched from a server, so there is no list of previously issued identifiers anywhere — reload the page and these are gone.

Version 4 and version 7

A v4 UUID is 122 random bits with six bits fixed to mark the version and variant. It is the right default when an identifier should carry no information at all.

A v7 UUID, standardised in RFC 9562, puts a 48-bit millisecond timestamp in the leading bits and fills the rest with randomness. Because the timestamp comes first, v7 values sort by creation time as plain strings — which keeps database indexes appending at the end instead of writing all over a B-tree. The trade-off is that a v7 identifier leaks roughly when it was created.

Layout	Meaning
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx	v4: the 4 is the version nibble; y is 8, 9, a or b (the variant).
tttttttt-tttt-7xxx-yxxx-xxxxxxxxxxxx	v7: the leading 48 bits are Unix milliseconds.

Collisions

With 122 random bits, you would need on the order of a billion UUIDs per second for a century before a collision became likely. In practice UUID collisions come from bugs — a seeded or non-cryptographic random source, a reused value, a truncated column — rather than from probability.

Storing them

A UUID is 16 bytes. Stored as text with hyphens it takes 36 characters, so use a native uuid type where your database has one (PostgreSQL) or a BINARY(16) column where it does not. The hyphens are formatting, not data.

Questions

Should I use UUID v4 or v7?: v7 if the UUID will be a database primary key. It starts with a millisecond timestamp, so values generated over time sort together and insert into a B-tree index without fragmenting it. v4 is fully random, which is the right choice when the identifier should reveal nothing about when it was created.
Are these UUIDs random enough to be unguessable?: Yes. They come from the browser's crypto.getRandomValues(), which is a cryptographically secure source. A v4 UUID has 122 random bits. Note that a v7 UUID deliberately encodes its creation time, so it is unguessable but not opaque.
Can two generated UUIDs collide?: Not in practice. You would need to generate about 2.7 × 10^18 v4 UUIDs before a collision becomes as likely as not. The realistic risk is a broken random source, not the maths.