Developer tools · UUID generator
RFC 4122 vs RFC 9562: What Changed in the 2024 UUID Standard
· Background
uuid cryptography browser-apis
Two RFCs are cited for UUIDs and they do not say quite the same thing. This post walks through what RFC 9562 added, clarified and deprecated relative to RFC 4122.
Which RFC do I cite? — the confusion when documentation and libraries reference different standards
Two RFCs are routinely cited in UUID documentation, and they do not say identical things. RFC 4122, published in 2005, defined UUIDs and their five versions (v1 through v5). RFC 9562, published in 2024, obsoletes RFC 4122 entirely, clarifies ambiguities that practitioners worked around, adds three new versions (v6, v7, v8), and updates guidance on implementing randomness. When a library cites RFC 4122, it is not wrong—that library may have been released before RFC 9562 was published or maintainers may not have updated documentation. Checking RFC citations tells you when a library was last significantly updated. When writing new specifications or evaluating implementations, RFC 9562 is the normative reference.
Obsoleting, not replacing the format — everything valid under RFC 4122 remains valid; the layout and variant bits are unchanged
RFC 9562 formally obsoletes RFC 4122 as the current reference document while retaining the familiar 128-bit representation, hexadecimal groups, version position and principal variant layout. Existing stored UUID strings do not need to be reissued merely because a newer RFC exists. The practical migration is in documentation, generators and validation policy: cite the current standard, understand the added versions, and check whether old code relied on an ambiguity the revision clarified. Compatibility should still be tested at system boundaries, especially where a library serializes Microsoft GUID structures or enforces a narrower set of versions than the standard describes.
Three new versions — v6 (reordered time), v7 (Unix-epoch time-ordered) and v8 (implementation-defined)
RFC 9562 adds three new versions to the standard. Version 6 reorders the v1 timestamp bits to produce lexicographically sortable identifiers for better database performance. Version 7 uses a 48-bit Unix millisecond timestamp followed by random bits, providing time-ordered generation without v1's privacy concerns. Version 8 is an escape hatch for implementation-defined layouts. None of these versions alter how v1-v5 work or what they mean. A v1 UUID from 2005 and a v7 UUID from 2024 can coexist in the same database, each with its version bits identifying its generation method. The three new versions address common patterns that emerged in practice.
Max UUID joins Nil — the all-F value defined alongside the all-zero one
RFC 4122 documented the Nil UUID (all zero bits) as a special reference value in examples and documentation. RFC 9562 includes the same Nil definition but formally defines the Max UUID (all bits set to one) for range boundaries. Neither Nil nor Max is a version 4 random UUID because they do not have correct version and variant bits. The Max UUID is useful as an upper-bound range boundary in database queries: WHERE uuid_column <= MAX_UUID matches all possible UUIDs. Nil is useful as a sentinel for unassigned in nullable UUID columns. RFC 9562 documents both without mandating their use in application data.
Clarified guidance — explicit advice to use a CSPRNG for random fields, on monotonic counters within a millisecond, and on preferring time-ordered versions for database locality
RFC 9562's best-practice guidance distinguishes collision resistance from unguessability. Random fields should use a source appropriate to the application's threat model, and security-sensitive opacity calls for a CSPRNG. Time-based generators have a separate monotonicity problem when several identifiers share one timestamp tick; the standard describes counters and additional timestamp precision as possible methods, each with state and rollover rules. Name-based versions remain deterministic identifiers, not proofs of authenticity. These clarifications matter because one UUID parser can accept all of the layouts even though their generation requirements and information-disclosure properties differ.
Where ULID's ideas show up — how the community format influenced v7's design
RFC 9562 says its authors analyzed several existing sortable identifier schemes, including ULID, Snowflake and KSUID, while developing the new layouts. That supports a modest conclusion: operational demand for time-ordered, distributed identifiers informed the revision. It does not prove that one community format donated an exact field layout to version 7. The practical similarity is enough for architecture work: these families place time information near the front so ordinary ordering can preserve broad creation order, then differ in encoding, coordination and within-tick behavior. Choose between them by ecosystem compatibility and documented guarantees rather than a claim of direct ancestry.
What this does not cover — a line-by-line diff; this post follows the practical consequences for implementers
This comprehensive post follows practical consequences and implementation of RFC 9562 for implementers and users, not line-by-line diffs against RFC 4122. The full specifications are available from standards bodies and are worth reading for implementing UUID handling in languages or platforms—the text provides authoritative detail beyond what an overview can cover. This post does not describe bit-level mechanics of how v6 reorders v1 bytes or how v7 encodes Unix milliseconds. Both the standards and implementation guides remain the primary authoritative reference for any implementation question regarding bit layout, encoding, or compliance verification.
Takeaway: update your citations and your defaults — the ToolAcre generator follows the CSPRNG guidance both RFCs share
For any new work, update documentation and specifications to cite RFC 9562. Every UUID from RFC 4122 remains valid under RFC 9562—migration is purely forward-looking and administrative in nature. The clarified guidance on cryptographic randomness reinforces that identifiers must come from cryptographically secure sources in production systems. ToolAcre follows the cryptographic randomness guidance from both RFCs, using the browser's Web Crypto API exclusively. When you encounter a UUID from logs, database exports, or API responses, the ToolAcre well-formed check reports its version and variant against RFC 9562. RFC 9562 is clarification and modernization of an already-stable standard.