UUID v4 vs v7: Random or Time-Ordered IDs? (Free Tool)

UUID v4 vs v7 comes down to one thing: v4 is entirely random, while v7 begins with the current time in milliseconds, followed by random bits. That makes v7 IDs sort in the order they were created, which is kinder to database indexes and handy for logs. Use v7 for new database primary keys; use v4 when IDs must reveal nothing, including when they were made. The free UUID generator makes both, up to 1,000 at a time.

UUID v4 vs v7: the short answer

	UUID v4	UUID v7
Built from	122 random bits	48-bit Unix time in ms + 74 random bits
Sorts by creation time	No	Yes (to the millisecond)
Reveals when it was made	No	Yes
Database index behaviour	Inserts scatter across the index	Inserts append near the end
Support	Everywhere	Newer; growing in libraries and databases
Standard	RFC 4122, now RFC 9562	RFC 9562 (May 2024)

Both are 128 bits, both look the same (36 characters, 8-4-4-4-12), and both fit in any column or field that accepts a UUID. You can mix them in one table, although you lose v7's ordering benefit for the v4 rows.

How each one is built

Version 4 sets 6 bits to mark the version and variant and fills the other 122 with random data:

7cf3d539-08e6-495b-b156-b4a5d2e4c963
              4 = version

Version 7, defined in RFC 9562, puts a 48-bit Unix timestamp in milliseconds at the front, then the version digit, then random bits:

01a181bc-da80-729c-86fc-6e6af14e610b
|------------|  timestamp: 0x01a181bcda80 ms
               7 = version

Because the timestamp sits in the most significant position, sorting v7 UUIDs as text or as bytes sorts them by creation time. 48 bits of milliseconds won't run out until the year 10889.

Read the time inside a v7 UUID

You can recover the creation time from any v7 UUID by hand:

1. Take the first 12 hex digits, ignoring the hyphen: 01a181bcda80.
2. Convert from hex to decimal with the number base converter: 1793178000000.
3. Paste that into the Unix timestamp converter, which spots a 13-digit millisecond timestamp. It shows 28 October 2026, 09:00:00 UTC.

That's useful when you're debugging ("when was this record created?"), and it's exactly why v7 is the wrong choice when creation time should stay private.

Why databases care: index locality

Most databases store a primary key in a B-tree index, kept in sorted order. Where a new key lands in that order matters:

• v4 keys land anywhere. Each insert goes to a random spot, so the database touches pages all over the index. Pages split half-full, more of the index has to stay in memory, and write-heavy tables slow down as they grow. On MySQL's InnoDB, where rows are physically stored in primary-key order, the effect is especially noticeable.
• v7 keys land near the end. New IDs are always bigger than recent ones, so inserts go to the right-hand edge of the index, like an auto-increment number. Pages fill up neatly and the "hot" part of the index stays small.

How big the difference is depends on your database, hardware and table size, so measure it on your own workload if it matters. The direction is consistent, though: time-ordered keys index better than random ones. As a bonus, ORDER BY id on v7 keys gives roughly creation order, and recent rows sit together, which suits "latest 50" queries.

Same millisecond, still in order

Busy systems create many IDs in the same millisecond. RFC 9562 gives several ways to keep those in order. EveryApp's generator uses its "method 1": the 12 bits after the version digit act as a counter within the millisecond, starting from a random value and counting up. Generate 1,000 v7 UUIDs at once and you'll see them come out in strictly increasing order, even though they share timestamps.

When to choose v4

• The ID will be public, for example in a URL or an email, and you don't want to reveal when the account or document was created.
• Your platform doesn't support v7 yet, or a library or integration specifically expects v4.
• Ordering doesn't matter, such as for idempotency keys, correlation IDs in logs, or file names.
• You need the maximum randomness. v4 has 122 random bits; v7 has at most 74, and fewer when a generator (like ours) uses 12 of them as a counter. Both are far beyond collision worries, because the remaining random bits per millisecond are still an enormous space.

When to choose v7

• New database primary keys, especially in large, write-heavy tables.
• Event logs, messages and queues, where sorting by ID should mean sorting by time.
• Distributed systems that want IDs made on many machines to interleave sensibly by time, without a central counter.

One caution: a v7 UUID's time is whatever the creating machine's clock said. If clocks across your servers drift, the order is approximate. Don't use the embedded time as an audit timestamp; keep a proper created_at column.

Neither is a secret

Whichever version you pick, a UUID is an identifier. Don't use one as an API key, password or the only protection on a private link. For background on the format, versions and collision odds, see what is a UUID. For secrets, use the password generator.

Generate v4 or v7 now

Pick v4 (random) or v7 (time-ordered), set how many, and click Generate. Tick Uppercase or Curly braces { } (or untick Hyphens, which starts ticked) for the format you need, then copy them or download a .txt file. The free UUID generator works on your device and never sends the IDs anywhere.