Which version you want

If you are generating an identifier that will be stored as a database key, you almost certainly want v7. For anything else — a correlation ID, a filename, an idempotency key — v4 is fine and is what most libraries still give you by default.

The difference is ordering. A v4 UUID is 122 random bits, so consecutive values land in unrelated places. A v7 UUID starts with a millisecond timestamp, so values generated close together sort close together, both lexically and as bytes.

Why that matters for a database

B-tree indexes like inserts that arrive in roughly increasing order: the hot pages stay in memory and the tree grows at one edge. Random v4 keys defeat this. Every insert lands on an arbitrary page, so the working set becomes the whole index, page splits happen everywhere, and the index fragments. On a large table the difference between v4 and v7 primary keys is visible in write throughput and in how much of the index has to stay resident.

v7 restores that locality while keeping the properties you chose a UUID for — generated anywhere, no coordination, no central sequence. The cost is that the creation time is embedded in the value and is trivially readable, which is a leak if the row's existence is meant to be private.

What is inside a v7

Field	Bits	Contents
`unix_ts_ms`	48	Unix timestamp in milliseconds, big-endian
`ver`	4	Version, always `0111`
`rand_a`	12	Random, or a counter for ordering inside one millisecond
`var`	2	Variant, always `10`
`rand_b`	62	Random

This generator uses rand_a as a counter, which RFC 9562 permits. That means a batch of ten thousand generated in the same millisecond comes out strictly ascending rather than shuffled within each millisecond — the property you actually wanted when you chose v7. If the counter saturates, the timestamp borrows from the next millisecond rather than repeating a value.

A UUID is not a secret

This catches people out, and the two versions differ:

v4 from a cryptographic RNG carries 122 unpredictable bits. Using one as an unguessable link token is defensible.
v7 carries 74 random bits alongside a timestamp anyone can read. If an attacker knows roughly when a record was created, the search space is far smaller than the length of the string suggests. Do not use v7 as a capability token, a password reset link, or a session identifier.

For anything that must be unguessable, generate a dedicated random token rather than reusing an identifier that also has to be a database key.

Collisions

For v4, the probability of a duplicate reaches roughly one in a billion only after about 10¹⁵ UUIDs. In practice the risk is not the mathematics but the source of randomness: a UUID built on Math.random, or on a seeded RNG in a test harness, collides readily. This tool uses crypto.getRandomValues. If you are generating UUIDs in your own code, check what your library is actually calling.

Common questions

Are these uploaded anywhere?: No. Generation happens in your browser and the page makes no network requests. See the privacy policy.
Why is my v7 batch not sorted when I check it?: It should be. If it is not, you are probably comparing formatted output after ticking "No hyphens" against unformatted values, or sorting as text with mixed case. Uppercase and lowercase hex sort differently.
Can I get the timestamp back out of a v7?: Yes — the first twelve hex characters are the millisecond timestamp. Parse them as a base-16 integer and pass the result to your date constructor.
What about v1?: v1 embeds a MAC address and a 100-nanosecond clock. It leaks hardware identity and its ordering guarantees are weaker than v7's. There is no good reason to choose it for new work.
Should I store UUIDs as text?: Only if you have to. A UUID is 16 bytes; stored as a 36-character string it is more than twice the size, and every index comparison is a string comparison. Postgres has a native uuid type and MySQL can use BINARY(16).