UUID versions explained: v1 vs v4 vs v7

What every UUID has in common

A UUID (Universally Unique Identifier, also called a GUID) is a 128-bit value written as 32 hexadecimal characters in five hyphen-separated groups: 8-4-4-4-12. Six of those bits are fixed: four version bits that record which generation method produced the value, and two variant bits that mark the layout. Everything else depends on the version.

The current standard is RFC 9562, published in 2024, which replaces RFC 4122 and defines eight versions. You can read the version straight out of a value: the first character of the third group is the version number. In 919108f7-52d1-4320-9bac-f847db4148a8, the 4 that starts the third group marks it as version 4.

UUID v1: timestamp plus node ID

Version 1 is the original time-based UUID. It combines a 60-bit timestamp counting 100-nanosecond intervals since 15 October 1582 (the start of the Gregorian calendar), a 14-bit clock sequence that guards against clock resets and duplicates, and a 48-bit node ID identifying the generator.

Historically, the node ID was taken from the generating machine’s network-card MAC address. That makes classic v1 values more revealing than they look: anyone holding one can read off roughly when it was created and, on systems that used a real MAC address, an identifier tied to the machine that created it. The standard now recommends a random node ID instead, and many modern generators use one, but you cannot tell from a value alone which choice its generator made.

One more surprise: despite embedding a timestamp, v1 values do not sort by creation time. The timestamp’s least significant bits are stored first, so sorting v1 values as text or bytes scatters them rather than ordering them chronologically.

UUID v4: random

Version 4 is the simplest to reason about: apart from the six fixed version and variant bits, all 122 remaining bits are random. A v4 value encodes no timestamp, no machine identity, and no sequence — nothing about when, where, or in what order it was created.

Uniqueness is probabilistic rather than guaranteed: with 122 random bits, collisions between properly generated values are extremely unlikely, but no registry enforces it. And randomness does not make a UUID a secret — treat any UUID as an identifier, never as a password, token, or other security capability.

This is the version our UUID v4 Generator creates, locally in your browser.

UUID v7: time-ordered random

Version 7 is new in RFC 9562 and was designed for exactly the case where v4 keys hurt: database indexes. A v7 value starts with a 48-bit big-endian Unix timestamp in milliseconds, followed by 74 bits of randomness (which some generators partly use for extra timestamp precision or a counter).

Because the most significant bits are the timestamp, v7 values sort by creation time. That matters for B-tree indexes, the structure behind most relational database primary keys: new v7 keys land near the end of the index instead of at random positions throughout it, which keeps recently used index pages hot and avoids the scattered inserts that random v4 keys cause.

Two caveats. First, the ordering property is also a disclosure: anyone holding a v7 value can read its creation time to the millisecond. Second, values created within the same millisecond are not guaranteed to sort in creation order unless the generator implements one of the RFC’s optional monotonicity techniques.

v1 vs v4 vs v7 at a glance

When to use each version

A short decision guide:

• Choose v4 when an identifier should reveal nothing. It is the safest default for API resource IDs, correlation IDs, and anything user-visible, because the value carries no timestamp, order, or machine information.
• Choose v7 when values will be indexed or sorted. Database primary keys, event records, and log entries benefit from time-ordered inserts — as long as a readable creation timestamp is acceptable for your data.
• Use v1 mainly when an existing system requires it. For new designs, v7 covers the time-based use case with better sorting and a cleaner privacy story.

Whichever version you choose, the same rule applies: a UUID identifies things; it does not protect them. Access control has to come from somewhere else.

The other UUID versions in brief

RFC 9562 defines five more versions you will meet less often. Versions 3 and 5 are name-based: they hash a namespace and a name (with MD5 and SHA-1 respectively), so the same input always yields the same UUID. Version 2 is a rarely used DCE security variant of v1. Version 6 reorders v1’s timestamp fields so values sort chronologically, easing migration from existing v1 systems. Version 8 reserves the layout for custom, application-defined values — only the version and variant bits are fixed.

Generate a UUID in your browser

Our UUID v4 Generator creates version 4 values only — random, RFC 9562-compliant, generated locally in your browser with Web Crypto and never sent to a server. It does not generate v1, v7, or any other version. If you need a v7 value, many standard libraries and popular UUID packages now offer one.