Toolsyy
Blog

UUID v4 vs v7: Which Should You Use?

Published August 2026 · Toolsyy Team

A UUID is a 128-bit identifier you can generate anywhere, on any machine, with no coordination — and be confident nobody else will ever produce the same one. Toolsyy’s UUID Generator makes them in bulk, in two flavours. Which flavour you pick has real consequences.

v4: random

Version 4 is what most people mean by “a UUID.” It is 122 random bits, with six bits reserved to mark the version and variant. Nothing about it is derived from the time, the machine, or anything else. 

f47ac10b-58cc-4372-a567-0e02b2c3d479
             ↑
             the 4 marks version 4

That randomness is the whole point: two systems that have never communicated can both generate IDs and never clash. The odds of a collision are so small they can be ignored — you would need to generate billions of UUIDs before duplication became a realistic concern.

v7: time-ordered

Version 7 replaces the leading 48 bits with a Unix timestamp in milliseconds, followed by random bits: 

01a0536d-d018-7000-9847-aed437508289
└──── timestamp ────┘↑
                     version 7

Because the timestamp comes first, sorting v7 UUIDs as plain text sorts them chronologically. That single property is the reason v7 exists.

Why ordering matters: the database problem

This is the practical reason to care, and it’s not obvious until you’ve hit it.

Databases store indexes as B-trees, kept in sorted order on disk. When you insert a row, its key goes wherever it belongs in that order.

With random v4 keys, every insert lands in an unpredictable spot in the index. As the table grows the index no longer fits in memory, so each insert touches a different page on disk, and the cache stops helping. Pages also split repeatedly as values are wedged into the middle, which fragments the index and inflates its size. Insert throughput degrades as the table grows — and it degrades quietly, so it usually surfaces long after the schema is set.

With time-ordered v7 keys, every new value is larger than the last, so inserts append to the end of the index. One page stays hot in memory, there are no mid-tree splits, and the index stays compact. You keep the “generate anywhere without coordination” benefit of UUIDs without paying the write penalty.

The subtlety: same-millisecond ordering

A timestamp alone isn’t quite enough. Generate five hundred v7 UUIDs in a single millisecond and they all share the same timestamp — if the rest is purely random, they shuffle among themselves and the ordering guarantee breaks exactly when you’re inserting fastest.

RFC 9562 solves this with a counter in the bits immediately after the version nibble — the next place a sort looks. Toolsyy implements it, so a batch generated in the same millisecond still comes out strictly in order. Generate 500 at once and sort them: the order is unchanged.

So which should you use?

Use v7 when:

  • The ID is a database primary key — this is the big one.
  • You want records naturally ordered by creation without a separate column.
  • You’re generating IDs at high volume.

Use v4 when:

  • The ID is public and creation time is sensitive. A v7 UUID openly reveals when it was made — fine for an internal row, not always fine for a share link.
  • You don’t want IDs to reveal ordering. Sequential-looking identifiers let people infer volume, or notice that two records were created moments apart.
  • You need maximum compatibility. v4 is universally supported; v7 is newer.

A reasonable default: v7 for internal keys, v4 for anything exposed to the outside world.

A note on randomness

The mathematics of collision resistance only holds if the random numbers are genuinely unpredictable. Toolsyy uses the browser’s crypto.getRandomValues, the cryptographically secure source — not Math.random, which is fast, predictable, and has produced real collisions in real systems. A weak generator is a much more realistic failure than the odds ever being against you.

FAQ

What is the difference between UUID v4 and v7?

A v4 UUID is entirely random. A v7 UUID begins with a millisecond timestamp, so v7 values generated later always sort after earlier ones. Both are unique; the difference is that v7 values arrive in order, which makes them far better as a database primary key.

Does a v7 UUID leak information?

It reveals the time it was created, to the millisecond, because that timestamp is part of the value by design. That is usually harmless for a database row but is a real consideration for anything public, such as an unguessable share link, where the creation time might be sensitive.

Can two UUIDs ever collide?

In practice, no. A v4 UUID contains 122 random bits, which is a large enough space that generating billions of them still leaves the chance of a duplicate negligible. This tool uses the browser cryptographically secure random source rather than Math.random, which matters because a weak generator is a far more realistic risk than the mathematics.

Are UUIDs generated here unique to me?

Yes. They are generated in your browser and never transmitted or recorded anywhere, so nobody else receives the same values and no server ever sees them.

Related guides

Try it now: Free UUID Generator