iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For a new system that needs IDs to sort roughly by creation time, choose UUIDv7 if your runtime has a sound implementation. Choose UUIDv4 for random IDs without time ordering, UUIDv5 for repeatable IDs derived from a namespace and name, and UUIDv6 mainly when maintaining a UUIDv1-based system. UUIDs identify records; none should be used as an authorization secret.
What UUID versions mean
UUID versions are different layouts and generation methods, not a ranking in which the highest number is automatically best. The current specification is IETF RFC 9562, published in May 2024, which supersedes RFC 4122 and defines UUID versions 1 through 8. The Java UUID API lists their types.
| Version | How it is generated and what it offers | Practical use |
|---|---|---|
| UUIDv1 | Time-based, with a node identifier and clock sequence. | Usually a legacy choice for new systems; a MAC-based node can expose network-address information. |
| UUIDv2 | DCE security UUID format. | Specialized legacy format; the cited standards and API sources do not give a general recommendation for new application IDs. |
| UUIDv3 | Name-based UUID generated with MD5. | Keep for compatibility. RFC 9562 recommends v5 instead where possible. |
| UUIDv4 | Random or pseudorandom bits, with version and variant bits set. | Random identifiers when natural time ordering is unnecessary. |
| UUIDv5 | Name-based UUID generated with SHA-1. | Repeatable identifiers from a stable namespace and canonical name. |
| UUIDv6 | Reorders v1-compatible timestamp fields. | Primarily for v1 compatibility and improved database locality; RFC 9562 recommends v7 for systems without a v1 legacy requirement. |
| UUIDv7 | Uses Unix-epoch milliseconds in its most significant bits, followed by random data and optionally monotonicity fields. | Preferred for new time-ordered identifiers when a suitable implementation is available; it exposes approximate creation time. |
| UUIDv8 | Custom or vendor-specific layout. | Use only for a documented need not met by standard versions. The standard does not guarantee uniqueness for a custom layout. |
Choose a UUID version by requirement
For new IDs that should sort roughly by creation time: UUIDv7
UUIDv7 places a 48-bit Unix-epoch timestamp in milliseconds in the most significant bits. Its remaining 74 usable bits are normally random, though implementations may use optional sub-millisecond and counter fields to improve monotonicity. The RFC says implementations should use v7 instead of v1 and v6 if possible. This gives approximate chronological ordering in compatible bytewise or lexical representations, not a globally authoritative event sequence: clocks can change, and separate generators do not establish causal or database-commit order. Because the timestamp is part of the ID, it also reveals approximate creation time.
For random IDs without time ordering: UUIDv4
Use v4 when random identifiers are appropriate and the timestamp ordering and visibility of v7 are not needed. RFC 9562 describes 122 random bits after the version and variant bits are assigned. Use an implementation backed by a suitable random or pseudorandom generator; do not treat unpredictability as a security guarantee.
#1 Best Overall
For repeatable IDs derived from a name: UUIDv5
Use v5 when the same namespace and canonicalized name must produce the same UUID. The namespace and normalization rules must remain stable: changing either changes the result. UUIDv3 is the older MD5-based alternative, generally kept for compatibility; RFC 9562 recommends v5 in its place where possible. If a policy requires SHA-256 or a newer hash for name-derived UUIDs, the RFC points to a custom v8 design rather than v5.
For systems already using UUIDv1: UUIDv6
UUIDv6 rearranges v1’s timestamp fields so they sort more conveniently for database locality. It is mainly a transition or compatibility option for systems already using v1; it does not by itself remove the privacy considerations associated with legacy node behavior. For a new time-ordered design without that constraint, the RFC recommends v7.
For a custom layout: UUIDv8
Before defining a custom epoch, hash, or embedded fields, check whether a standard version already meets the requirement. UUIDv8 leaves the layout to an implementation-specific algorithm. Document that algorithm and its interoperability and uniqueness properties; setting the version and variant bits alone does not establish uniqueness.
Compare the trade-offs before choosing
| Version | Ordering | Determinism | Information exposure | Compatibility or policy fit |
|---|---|---|---|---|
| v1 | Time-based, but not the preferred new time-ordered choice in RFC 9562. | Generated per implementation; not a name-derived mapping. | A MAC-based node may expose network-address information. | Legacy use; can be relevant when maintaining existing systems. |
| v2 | Not established as a general-purpose ordering choice by the cited sources. | Not established as a general-purpose name-derived choice by the cited sources. | Not stated as a general recommendation by the cited sources. | Specialized DCE security legacy format. |
| v3 | No time ordering from its name-derived format. | Repeatable for the same namespace and name under consistent rules. | No embedded creation timestamp described in the cited format summary. | MD5-based; retain mainly for compatibility when v5 is not an option. |
| v4 | No natural time ordering. | Random or pseudorandom, not name-deterministic. | No embedded timestamp described in the cited format summary. | General option for random IDs; not a security capability. |
| v5 | No time ordering from its name-derived format. | Repeatable for the same namespace and canonical name. | No embedded creation timestamp described in the cited format summary. | SHA-1-based; suitable when that hash policy is acceptable. |
| v6 | Reordered time fields support database locality. | Generated per implementation; not a name-derived mapping. | May retain legacy node behavior; reordering alone does not remove privacy concerns. | For v1 transition or compatibility; v7 is recommended otherwise. |
| v7 | Approximate chronological sorting from its millisecond timestamp; not a transaction sequence. | Normally random data, with optional monotonicity fields. | Reveals approximate creation time. | Preferred new time-ordered option when supported by the runtime. |
| v8 | Depends on the custom layout. | Depends on the documented implementation-specific algorithm. | Depends on the custom fields. | For requirements not met by standard layouts; uniqueness and interoperability depend on the design. |
Keep UUID privacy and security limits in mind
UUIDs are identifiers, not secrets
RFC 9562 warns that implementations must not assume UUIDs are hard to guess or use them as security capabilities. Do not grant access merely because someone possesses a UUID. Use a separate authorization mechanism and, when a secret token is needed, a purpose-built secret with appropriate security properties.
Rank #3
Consider what an ID reveals
UUIDv7 embeds a timestamp, which can expose approximate creation time. UUIDv1 may include a MAC-based node identifier; the RFC warns about privacy and network-security concerns. Python’s official UUID documentation likewise warns that uuid1() may compromise privacy because the generated UUID contains the computer’s network address. UUIDv6’s reordered fields do not, by themselves, eliminate legacy node-related concerns.
Check runtime support before adopting a version
Support depends on the language, runtime, and library version. For example, the Python standard-library documentation reviewed lists generators for v1, v3, v4, and v5; it does not list a standard-library v7 generator. Verify the API and behavior in the actual deployment stack rather than assuming a version exists everywhere.
Quick Recap
Rank #4
- Used Book in Good Condition
- Confirm that the runtime or library supports the UUID version you plan to generate.
- Check its random-source quality, behavior under concurrent generation, and response to clock rollback if using a time-based version.
- Confirm serialization, byte-order conventions, and how the application sorts UUIDs in its database and APIs.
- Test generation and sorting across all services that create or consume the IDs.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
