]> Cisco Systems

kydavis@cisco.com kyzer.davis@outlook.com

ART uuidrev uuid encoding base02 base10 base16 base32 base36 base52 base58 base62 base64 base85 This document presents considerations and best practices for alternate Universally Unique Identifier (UUID) encoding methods observed in the industry. This document updates RFC9562 to provide suggested alternate encoding methods, best practices and the various implementation considerations required for choosing the correct encoding for an application. When selected correctly, these alternate UUID encodings perform better on the wire, in a database, or within various other application logics versus the unnecessarily verbose text representation from RFC9562. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Revise Universally Unique Identifier Definitions (uuidrev) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The original "hex-and-dash" (8-4-4-4-12) canonical format of UUIDs defined in represents a 128-bit UUID value as a 288-bit text value. Although this format is useful for human readability, it is verbose for storage, transmission, and application parsing. Because of this, developers have long used alternate UUID encodings. Many bespoke implementations—either within a single application or as one-off libraries—address shortcomings of the hex-and-dash form. However, most applications, databases, and standard libraries expose UUIDs exclusively using the formats described in IETF documents. If a feature is not specified by a well defined standard, implementers typically do not provide that feature and users do not see those capabilities. Consequently, although alternate encodings have been used and reimplemented for many years, there is no single applicable standard and implementations are inconsistent. During the revision process that produced UUIDv6, UUIDv7, and UUIDv8 for , alternate encodings were a major topic of discussion. The level of interest showed that a separate document focused on alternate encodings was needed. This document describes the most common alternate UUID encoding methods observed in the field and discusses the advantages and disadvantages of each. The latter half of the document presents best practices and considerations implementations should weigh when selecting, implementing, or defining new alternate UUID encodings not covered in . These best practices are based on years of research, community feedback, and inspection of over 55 alternate-encoding implementations across 17 alphabets (see ).

Terminology

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Abbreviations The following abbreviations are used in this document:

UUID

Universally Unique Identifier

BaseXX

Base where XX references two numeric values with any leading 0 kept. For example Base02, Base10, Base16, Base32, Base64, etc.

Alternate UUID Encoding Methods details that at its core, any given UUID is a 128 bit value which can be represented as Base02 (binary), Base10 (decimal/integer), Base16 (hex) and even a custom "hex-and-dash" string format; which is Base16 (hex) with a few extra dash characters added to create a unique UUID string format that is instantly recognizable. Further, the section goes on to discuss other string formats that often use the Hex and Dash format or Integer format. While these are the "well-known" UUID formats, a UUID is fundamentally a 128-bit value and can be represented using many BaseXX alphabets. The large number of possible BaseXX alphabets, together with the considerations described in , makes it impractical to cover every alphabet variant in a single document. Therefore, this document focuses on BaseXX alphabets that use US-ASCII () and that are most commonly used in real-world implementations or were prototyped during the draft's preparation. UUID library implementers SHOULD consider adding support for at least one alternate encoding described here and MAY support additional encodings, including ones not listed. If you implement a BaseXX alphabet not covered in the sections below, consult the considerations in . For a quick comparison of alphabets, see . Encoding Variant Alphabet Order Base16 0123456789ABCDEF with four dash/hyphen - characters added Base16 0123456789ABCDEF Base32 ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 Base32 0123456789ABCDEFGHIJKLMNOPQRSTUV Base32 0123456789ABCDEFGHJKMNPQRSTVWXYZ Base36 --- 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ Base52 --- ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz Base58 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz Base62 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 Base62 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz Base64 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ Base64 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_ Base64 -0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz Base85 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-:+=^!/*?&<>()[]{}@%$# There also exist some algorithms that perform some pre-processing on the binary encoding of the UUID before encoding it as one or more of BaseXX Alphabets from the for very specific application use-cases. The specifics about each algorithm are covered in their own documents but are included here for completeness and comparison purposes; see and for the real-world problems these solve within databases and other applications. The table compares these different algorithms. Encoding Alphabet(s) and notes , ,
Version and Variant extracted and placed at the start and end of the layout to "Bookend". 26, 23 and 22 character outputs for the different alphabets in use.
130-bit post-processed UUID value by appending 0b10, 22 characters after encoding Note: All UUID examples in this document are alternate encodings of 's Example UUID starting from either Figure 2 (binary) or Figure 3 (integer). Each section has a few example encodings; any UUID featured in RFC9562 can be found in the table converted to the corresponding BaseXX alphabet encoding.

Base32 Base32 alphabets generally use 5 bits per character, producing a 26-character output when encoding a 128-bit UUID; padding may be present. These alphabets include standards-based Base32 (), Base32hex (), Base32 for Humans (formerly known as Douglas Crockford's Base32), Z-Base-32 , and . Base32 alphabets vary the most in character choice because implementers can be selective about which characters are included. and alphabet ordering (see ) are important considerations and differ across implementations. Base32 is often case-insensitive: lowercase letters are frequently treated the same as uppercase because the alphabet does not require distinct upper- and lower-case characters. are rarely used with Base32, except for or features, which can often be omitted. Base32 is a strong choice when available. The standard Base32 alphabet () is not recommended for new UUID implementations because its alphabet does not preserve binary sort order; libraries currently providing this encoding need not deprecate it, but new implementations should use Base32hex or Base32 for Humans instead. Base32hex () is recommended when sorting is required. Base32 for Humans () is recommended when both sorting and human readability are required. See and for examples. Z-Base-32 makes many changes to the underlying alphabet to accommodate a specific use case and is not recommended for UUIDs. Although is closer to Base32hex and excludes some characters like the Base32 for Humans alphabet, its removal of trailing zeros is an unusual behavior not used by other BaseXX alphabets and may make adoption difficult. There are many other Base32 variants; consult when selecting an alphabet not listed here.

Base36 Base36 alphabets are similar to Base32 but use about 5.1699 bits per character, reducing a 128-bit UUID to 25 characters. Base36 typically uses digits 0–9 followed by uppercase A–Z, which affects case-sensitivity considerations (see ). Alphabet ordering matters: using an alphabet ordered as A–Z0–9 would change sort order and is therefore uncommon. Base36 also compresses leading null bytes (see ) which may be desirable to further reduce the size of the encoded UUID. Base36 is reasonably available () but does not have concrete specifications outlined by a standards body. Base36 is recommended when variable-length UUIDs are not a problem for the application. See for an example.

Base52 Base52 uses the 52 alphabetic characters A–Z and a–z, producing a 23-character UUID at about 5.700 bits per character. Although not widely used, Base52 has useful properties: it contains no special characters () and excludes digits, avoiding issues with leading digits in some contexts. Its ordering can be chosen to preserve desirable sort behavior (see ). Base52 also compresses leading null bytes (see ) which may be desirable to further reduce the size of the encoded UUID. Base52 does not have concrete specifications outlined by a standards body, but it is reasonably easy to implement. Base52 is recommended when sorting is required, special characters and digits pose problems, and variable-length UUIDs are not a problem. See for an example.

Base58 Base58, used by (and ), is a popular alphabet and similar to Base32 for Humans in its character exclusions. Base58 encodes a 128-bit UUID into a 22-character string (about 5.857 bits per character). Base58 typically omits , and most implementations follow the same alphabet, with the variant being a notable exception. Base58 also compresses leading null bytes (see ) which may be desirable to further reduce the size of the encoded UUID. Base58 varies, but the format is well-known and commonly used for UUIDs in practice. Base58 is recommended when sorting and human readability are required, and variable-length UUIDs are not a problem. See for an example.

Base62 Base62 is the largest BaseXX alphabet that contains no special characters (). Base62 encodes a 128-bit UUID as a 22-character string (about 5.954 bits per character). During research the authors observed a number of libraries or discussions specifically using Base62 for UUIDs. (defined by the IEEE) is one implementation and is a variant that preserves sort order. Both variants use the same set of 62 characters but in a different order: orders the alphabet as A–Za–z0–9 while orders it as 0–9A–Za–z to preserve lexicographic sort order (see ). Additionally, includes padding while does not. also compresses leading null bytes (see ) which may be desirable to further reduce the size of the encoded UUID. is recommended when variable-length UUIDs are not a problem. is recommended when sorting is required and special characters or digits pose problems. See for an example.

Base64 Base64 alphabets require special characters () to complete the 64-symbol set, so they typically do not use character exclusions. Base64 encodes a 128-bit UUID into a 22-character string (6 bits per character), similar in length to Base58 and Base62. Because symbols are involved, many other permutations exist and this document cannot cover them all; see when selecting an alphabet. The most common variants are the Base64 alphabet in , Base64url in and Base64sort () (also known as Base64lex). The standard Base64 alphabet () is not recommended for new UUID implementations; libraries currently providing this encoding need not deprecate it, but new implementations should use Base64url or Base64sort instead. Base64url () is recommended for most use cases because it is safe for URLs, filenames and use cases. Base64sort () is recommended when lexicographical sorting that matches binary order is critical (for example, with UUIDv6 or UUIDv7). Base64 alphabets enjoy widespread availability () and are far more common than Base32 as per an analysis of RFC4648 alphabet usage in the wild . See and for examples.

Base85 Base85 encodes 4 bytes as 5 characters (about 6.409 bits per character), so a 128-bit UUID can be represented in 20 characters. These alphabets include many special characters (), and provide the most compact textual representation among the alphabets discussed. Common variants include Z85, Base85, and ASCII85. Some Base85 variants include compression techniques for certain byte sequences (see ). Those techniques are not universal across all Base85 alphabets. Z85 is the recommended Base85 variant for UUIDs when symbols are not a concern. See for an example.

3:Stl> ]]>

UUID Encoding Best Practices There are several factors to consider when choosing an encoding for a UUID. Requirements that matter for one application may be irrelevant for another; the authors have grouped the most important considerations into best-practice categories in the sections that follow. Each section focuses on UUID-specific concerns, but many of the topics generalize to selecting alternate encodings for other data.

Usage Understanding how a UUID will be used is the most important step when choosing an alternate encoding. That analysis affects many of the considerations that follow. For example, a UUID used as a logging prefix should be compact to reduce log size, while a UUID that must be read or spoken by humans should avoid characters that are easily confused. Shorter encodings with character exclusions are preferable when values are recited by phone or written by hand to reduce transcription errors. Datastores (see ) care about case sensitivity, alphabet ordering, and encoded length because these factors affect sorting, storage, and performance at scale. UUIDs transmitted between machines benefit from extremely compact encodings to reduce bytes on the wire and improve behavior on limited-MTU or high-latency networks. For resource-constrained devices such as IoT endpoints, prefer encodings that are computationally inexpensive to encode and decode. For Large Language Model (LLM) applications, UUID encoding directly affects token consumption because each token maps to a variable number of characters and special characters often consume disproportionately more tokens. Shorter encodings that avoid special characters generally consume fewer tokens and reduce inference costs; . For a given application use case (database key, network transmission, logging, etc.), implementations SHOULD choose exactly one BaseXX encoding and MUST NOT mix different BaseXX encodings for the same purpose. Mixing encodings breaks assumptions about encoded length and sort order and complicates comparison logic. For example, if an application stores UUIDs as Base32 in a database, it should not also accept or produce Base62-encoded UUIDs for the same field. The general statement by the authors is as follows: there is no single correct choice to cover every scenario.

Maximum Character Length The number of characters/symbols in a given encoding alphabet is directly correlated to the size of the alternate UUID encoding output. As a starting point the encodings defined by RFC9562 are Binary, Integer, and Hex. Base02 (Binary) version of a UUID is 128 characters in length consisting of 0s and 1s. The Base10 (decimal/integer) version of a UUID is 39 characters consisting of characters 0 through 9 while the Base16 (Hex) version of a UUID shortens this to 32 characters by using characters 0 through 9 and A through F. Base32 libraries tend to produce a UUID output of 26 characters in length and base64 drops the output UUID to 22 characters. With this trend one may be tempted to simply pick the highest BaseXX encoding available and get the smallest encoding output possible however as the output encoding decreases, the base alphabet increases. At a specific point both numeric values, upper and lowercase values may be present and any number of unique symbols can be present in the base alphabet. The addition and ordering of these can have rippling effects that one must properly consider. Further, some of these alphabets require unique math to properly apply to the fixed-length 128 bit UUID which may increase computational complexity in unfavorable ways along with padding to output a similarly fixed-length value. Simply picking the biggest base alphabet to get the smallest encoding only works if the only consideration an implementation cares about is the actual size of the output UUID. To glean the maximum size of a given BaseXX encoding with a 128-bit UUID, convert the binary form of UUID MAX from . details the maximum length of various BaseXX Encoding methods with UUID MAX, without padding present. Encoding Variant Maximum Character Length Base16 36 Base16 32 Base32 26 Base32 26 Base32 26 Base36 --- 25 Base52 --- 23 Base58 22 Base62 22 Base62 22 Base64 22 Base64 22 Base64 22 Base85 20

Padding Characters Padding characters go hand in hand with the previous section involving the maximum character length of an output alternate UUID encoding. The most common padding character is the equal sign (=) however it could theoretically be any character possible. It is recommended to use the equal sign since it is the most well-known padding character among the various BaseXX encodings. Further, this character is almost always in the least significant, right-most section of a given alternate UUID encoding. The padding SHOULD stay in this position and moving the character can have ramifications for sorting. For example, Base64sort () allows for either the equal sign (=) or tilde (~) as a padding character, but only the tilde is valid for sorting because the equal sign is lexicographically less than all other characters in the alphabet. Since UUIDs defined by are always 128 bits, padding MAY be omitted and the resulting output will always be the same length. compares padding usage among the BaseXX encoding methods in this document. Encoding Variant Padding Base16 N Base16 N Base32 Y (=) Base32 Y (=) Base32 N Base36 --- N Base52 --- N Base58 N Base62 Y Base62 N Base64 Y (=) Base64 Y (=) Base64 Y (= or ~) Base85 N

Checksum Characters Some newer BaseXX encodings include checksum characters that are used to ensure the input/output encoding and decoding is working as expected. The actual character and algorithm used vary among BaseXX implementations. Including checksums increases both the maximum size of the output encoding and the computation requirements for encoding/decoding alternate UUID formats. For alternate UUIDs transmitted among two machines it may be beneficial to include a checksum character to validate the given UUID has not been modified during transport before using it for various operations thus increasing the resiliency of the alternate UUID generation and parsing process. For applications that simply care about generating UUIDs but do not need to parse, checksums MAY be omitted entirely. compares checksum usage among the BaseXX encoding methods in this document. Encoding Variant Checksums Base16 N Base16 N Base32 N Base32 N Base32 Y (*,~,$,=,U,u) Base36 --- N Base52 --- N Base58 Y (SHA256-based) Base62 N Base62 N Base64 N Base64 N Base64 N Base85 N

Special Characters After all of the alpha-numeric characters are used a BaseXX alphabet must resort to using special characters such as but not limited to underscore (_), hyphen (-), plus (+), forward slash (/), dollar sign ($), etc. This usually occurs around 62 characters (ten digits 0-9, 26 lowercase English characters, 26 uppercase English characters) but may happen with earlier BaseXX alphabets when specific characters are excluded. The inclusion of these characters decrease the overall size of the encoded UUID but have implications in regards to not just sorting and readability but often application usage. For example Base64 as defined by has two alphabets which change the special characters to ensure safe usage with URLs and Filenames. Another example is the ability to double-click a UUID and copy the value. When special characters are present the text highlight starts and stops between these characters. In such a scenario, if this is important one should implement a BaseXX Alphabet with no such characters. When evaluating a baseXX encoding, care must be taken to ensure the special characters are compatible with the desired use case. compares special character inclusions among the BaseXX encoding methods in this document. Encoding Variant Special Characters Base16 Y (dash) Base16 N Base32 N Base32 N Base32 N Base36 --- N Base52 --- N Base58 N Base62 N Base62 N Base64 Y (plus, forward-slash) Base64 Y (dash, underscore) Base64 Y (dash, underscore) Base85 Y (numerous, see )

Character Exclusions Newer BaseXX alphabets may exclude characters, retaining only one character from each group of visually similar characters. This often occurs when multiple characters are similar in shape, which may lead to issues when humans are required to read the characters aloud or manually transpose the characters by hand. Some characters may be excluded for other non-obvious reasons like avoiding potential vulgar words or other application-specific issues. For example it may be advantageous to remove 0 as a possible option to eliminate the possibility of leading 0s in the output data which may lead to problems in specific use cases where leading 0s are not permitted or may be inadvertently removed by the application. Finally, in some smaller BaseXX alphabets it is possible to exclude characters because they are not required to fill out the space. The notable example is Base32hex defined by which only uses A through V because the remaining slots are filled by numeric 0-9. The following character groupings illustrate some of the problematic characters that are similarly shaped.

Unfortunately there is no consistent method for which character is omitted or removed. Some BaseXX alphabets may remove the numeric characters while others may remove one or both of the English characters, often replacing them with symbols in larger BaseXX alphabets to fill the gaps. Implementations should vet BaseXX alphabets with character exclusions thoroughly to ensure any possible inclusion of symbols does not cause problems while also verifying that sorting is not impacted if sorting is a requirement. compares character exclusions among the BaseXX encoding methods in this document. Encoding Variant Character Exclusions Base16 N Base16 N Base32 N Base32 N Base32 Y (Ii,Ll,Oo,Uu) Base36 --- N Base52 --- N Base58 Y (0,I,O,l) Base62 N Base62 N Base64 N Base64 N Base64 N Base85 N

Case Sensitivity Case sensitivity becomes important when the alphabet includes more than 32 characters. For alphabets at or below Base32 (for example, Base16), uppercase and lowercase characters are often treated interchangeably; for larger alphabets, uppercase and lowercase letters represent distinct values. In most scenarios, uppercase letters are ordered before lowercase letters. This ordering directly impacts sorting because many applications sort uppercase characters before lowercase characters. Sorting is further covered in . The BaseXX alphabet used also changes comparison logic: "aBc" does not necessarily equal "AbC" in all encodings. compares case sensitivity among the BaseXX encoding methods in this document. Encoding Variant Case Sensitive Base16 N Base16 N Base32 N Base32 N Base32 N Base36 --- N Base52 --- Y Base58 Y Base62 Y Base62 Y Base64 Y Base64 Y Base64 Y Base85 Y

Sorting and Ordering Lexicographical sorting of UUIDs is a very important factor to many applications and the ordering of the BaseXX alphabet directly impacts the sorting of the encoded UUID output such as those created by UUIDv6 and UUIDv7 where lexicographically sortable UUIDs are a key feature of the underlying algorithm. The BaseXX alphabets generally consist of two or more of the following 4 components with optional omissions as defined by :

The ordering of these is traditionally Numeric, Uppercase, Lowercase and Symbols. However for ordering purposes, some symbols may be placed at a different position to adhere to their position found in US-ASCII (). A common sorting example is a symbol like the dash (-) character may sort before numbers while other special characters such as an underscore (_) will be sorted after the uppercase characters but before the lowercase characters if sorted via their ASCII values. If an implementation would like to ensure the sort order of the encoded value remains the same as the Base02 (binary) or Base10 (decimal) value one should scrutinize the position of the underlying BaseXX alphabets, their ordering and the included symbols. illustrate the ordering trends for some common BaseXX Alphabets that adhere to the US-ASCII character set and their ordering of the various components.

compares binary sorting among the BaseXX encoding methods in this document. Encoding Variant Sorts the Same as Binary Base16 Y Base16 Y Base32 N Base32 Y Base32 Y Base36 --- Y Base52 --- Y Base58 Y Base62 N Base62 Y Base64 N Base64 N Base64 Y Base85 N

Compressing Characters Some BaseXX alphabets may use varying techniques for compressing null bytes (0x00), whitespace, or long runs of the continuous characters which can sometimes yield values smaller than what is cited in . , , , and will trim leading zero characters before attempting to encode the data. alphabets may employ a technique to compress a continuous four byte sequence of ASCII Space characters as the character lowercase y. alphabets may also compress a continuous four byte sequence of ASCII Zero characters as the character lowercase z. The leading zero compression technique can be observed in using NIL UUID input to illustrate the output featuring a much smaller value than the outputs found in other test vectors. This variability may be desirable to produce even smaller UUIDs however this could also prove a problem if an application expects a UUID of a specific fixed-length value found in .

Encoding Availability The BaseXX alphabet encoding availability may be the second greatest hurdle implementations navigate as they chose a viable alternate encoding for UUID. For example, traditional Base64url safe sees far more standard implementations than Base32hex as per while even fewer have implemented Base62 or Base36 variants. The ability to utilize a given encoding or provide a customized alphabet may be a limiting factor in implementations. In this scenario implementors will need to write their own, leverage third-party libraries or select a viable alternative. This is being addressed in some ways by standardizing documents such as or but there are still many BaseXX alphabets that do not have concrete specifications outlined by a standards body. Further, it takes time for a languages and applications to implement and adopt these standards and for the standards to be widely adopted by the community.

Computation The various base encodings have more or less computational requirements based on the size of the alphabet, the total number of bits encoded per character, if checksums are involved, and if floating point math is required (e.g radix-xx computations). For reference, Base02 uses 1 bit per character, Base10 uses about 3.322 bits per character, Base16 uses 4 bits per character, Base32 uses 5 bits, and Base64 uses 6 bits. While non–power-of-two alphabets like Base36, Base58, or Base62 use approximately 5.169, 5.857, and 5.954 bits per character respectively, the computation is log₂(XX) where XX is the alphabet length. compares bits per character among the BaseXX encoding methods in this document. Encoding Variant Bits per Character Base16 4.000 Base16 4.000 Base32 5.000 Base32 5.000 Base32 5.000 Base36 --- 5.169 Base52 --- 5.700 Base58 5.857 Base62 5.954 Base62 5.954 Base64 6.000 Base64 6.000 Base64 6.000 Base85 6.409

Parsing This document focuses on generating UUIDs via alternate formats rather than parsing UUIDs of alternate encoding formats. The generic default for any existing uuid_parse(uuid) function SHOULD remain that of hex-and-dash string format. Implementors MAY provide parse functionality to parse UUIDs of alternate formats such as uuid_parse(uuid, encoding="base64url"). The distribution (and naming) of the encoding algorithm among disparate systems is outside of the scope of this document. In practice this is seldom an issue because most implementations that need to parse UUIDs are aware of the encoding format used by their peers. For example, the sender and receiver of a Base64url-encoded UUID are often within the same application boundary. It is uncommon for two different systems to exchange UUIDs in a way that requires the receiver to parse an alternate-format UUID back into binary; typically the receiver treats the received UUID as an opaque string.

Application Specific Some applications have very specific restrictions which may influence the alternate UUID encoding selection. This section features a limited list compiling some known restrictions that implementations may consider while working with alternate UUID encodings.

LLM Token Efficiency Large Language Models (LLMs) process text using tokens: sub-word or character-level units whose boundaries depend on the model's tokenizer. Because UUID alternate encodings mix digits, uppercase letters, lowercase letters, and sometimes special characters in patterns that rarely appear in natural language, tokenizers often split them into many small tokens. Greater token consumption translates directly to higher inference cost, increased latency, and reduced effective context-window utilization. Tokenizer behavior varies substantially across vendors and model families. The token counts below were measured using the following tokenizers, which were current when this document was prepared: Anthropic: Claude OPUS 4.6 OpenAI: GPT5.x & O1/3 xAI: grok-4.20-0309-reasoning Google: Gemini 3.1 Pro Preview Generic: ceil(character_length / 4), the common "1 token ~= 4 characters" heuristic Note: The token counts in use the MAX UUID from which consists largely of repeating characters. Repeating characters compress very aggressively in Byte-Pair Encoding based tokenizers, so these values represent a best-case (minimum token) scenario. uses the Example UUID from whose mixed characters are more representative of typical UUIDs. Real-world token counts will more closely resemble the latter. details the token count for the MAX UUID across various BaseXX Encoding methods and tokenizers. Encoding Variant Anthropic OpenAI xAI Google Generic Base16 21 10 10 13 9 Base16 7 4 2 9 8 Base32 10 9 9 27 7 Base32 27 13 13 14 7 Base32 15 13 13 14 7 Base36 --- 10 10 10 27 7 Base52 --- 21 15 15 16 6 Base58 18 14 14 16 6 Base62 20 15 12 13 6 Base62 22 17 17 19 6 Base64 4 4 4 4 6 Base64 4 3 3 4 6 Base64 12 11 6 12 6 Base85 20 20 20 21 5 details the token count for a typical UUID () across various BaseXX Encoding methods and tokenizers. Encoding Variant Anthropic OpenAI xAI Google Generic Base16 26 25 21 33 9 Base16 22 22 15 29 8 Base32 22 17 16 19 7 Base32 20 18 17 22 7 Base32 21 18 16 22 7 Base36 --- 22 17 17 18 7 Base52 --- 20 14 15 14 6 Base58 17 15 14 18 6 Base62 20 14 16 17 6 Base62 21 16 15 16 6 Base64 20 16 14 18 6 Base64 20 16 14 18 6 Base64 21 16 14 17 6 Base85 19 15 14 16 5 Key takeaways: The commonly cited "1 token ~= 4 characters" heuristic severely underestimates real token costs for UUIDs. The generic column predicts 5-9 tokens, but official tokenizers return 14-33 tokens for a typical UUID, a 2-4x underestimate. Higher-base encodings (Base52+) generally produce fewer tokens than lower-base encodings (Base16, Base32) for typical UUIDs because the shorter character length outweighs the added alphabet complexity. For example, Base16 with hyphens costs 21-33 tokens across vendors while Base58-Base85 range from 14-19. Removing the hyphens from the standard Base16 UUID representation saves 4-7 tokens depending on the vendor (e.g., xAI: 21 to 15, Google: 33 to 29 for the example UUID). Base64 standard variants ( Section 4 and 5) are exceptionally efficient for repetitive inputs (3-4 tokens for MAX UUID) but converge with other high-base encodings (14-20 tokens) for typical UUIDs. Token counts vary substantially across vendors for the same input; for example, the standard Base16 UUID representation ranges from 21 tokens (xAI) to 33 tokens (Google) for the same UUID. Applications sensitive to token costs should measure with their target model's tokenizer.

URI, URL, URN Uniform Resource Identifiers (URIs) have a specific list of reserved characters defined by which require percent encoding to be used. It is advisable to avoid BaseXX alphabets that include these symbols.

DNS Record Domain Name Systems (DNS) are case insensitive with the period or dot character (.) being a reserved symbol. Thus BaseXX alphabets that utilize this character or use upper and lowercase values as defined by should be avoided.

XML, HTML, CSS Extensible Markup Language () namespaces cannot start with a leading numeric character. While older versions of Hypertext Markup Language () had restrictions on element identifiers starting with a leading digit, HTML5 does not have any such restrictions. The same goes for Cascading Style Sheet () selectors identifiers where older versions would have issues when identifiers start with digits. Thus for XML, HTML, and CSS it is advantageous to use some advanced methods such as: Leveraging the alternate UUID encoding technique defined via (UUID-NCName-32, UUID-NCName-58 or UUID-NCName-64) to ensure that the first digit is always an uppercase alphabet character. An alternative algorithm to the NCNAME method is to prefix a value like b10 as seen in to ensure the first character is always a letter. Utilize which ensures the output UUID does not start with a special character or digit. Simply prefix the first non-digit/non-special character in the given alphabet. For example, if uppercase A is available, prefix this character to satisfy the constraints.

Database Keys Databases often have specific requirements for keys such as case sensitivity, sorting, and maximum length. When using alternate UUID encodings as database keys, it is important to consider these requirements and select an encoding that meets them. Database implementors should consider when using alternate UUID encodings as database keys to ensure the first character is an uppercase alphabet character and the output is compact.

Security Considerations Section addresses the primary security-related concern in this document: data-integrity validation for UUIDs transmitted over the wire. No additional security considerations are identified.

IANA Considerations This document has no IANA actions.

This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. W3C whatwg W3C Geohash IEEE Bitcoin XRP Ledger iMatix Corporation

Acknowledgments The authors gratefully acknowledge the contributions of Yulian Kuncheff for their work on the UUID Formatter test tool (https://uuidformattester.yuli.dev/) which was valuable in comparing various UUID encoding formats side-by-side. LiosK for early prototyping of various BaseXX Alphabets Sergey Prokhorenko for continuously ensuring we work on this document. As well as all of those in the IETF community and on GitHub who contributed to the discussions which resulted in this document.

Changelog draft-00: Initial Release

Test Vectors The test vectors in the upcoming sections map the UUIDs found in RFC9562 Sections to their appropriate BaseXX Alphabet Encoding without padding. All of the BaseXX Alphabets described in this document and others not described can be viewed at the online tool the Authors are using for prototyping and comparison: https://uuidformattester.yuli.dev/ (Source Code: https://github.com/daegalus/uuid-format-tester) The NCNAME test vectors (UUID-NCName-32, UUID-NCName-58, and UUID-NCName-64) are direct copies from the appendix of . Each section also includes test vectors for which are not included in the main body of the document but are included here for reference.

Generic UUID Encoding Variant RFC9562, Section 4 Base16 f81d4fae-7dec-11d0-a765-00a0c91e6bf6 Base16 f81d4fae7dec11d0a76500a0c91e6bf6 Base32 7AOU7LT55QI5BJ3FACQMSHTL6Y Base32 V0EKVBJTTG8T19R502GCI7JBUO Base32 Z0EMZBKXXG8X19V502GCJ7KBYR Base36 --- EOSWZOLG3BSX0ZN8OTQ1P8OOM Base52 --- FraqvVvqUBoEOFXsPYOPwUm Base58 Xe22UfxT3rxcKJEAfL5373 Base62 HiLegqjbBwUc0Q8tJ3ffs6 Base62 7YBUWgZR1mKSqGyj9tVViw Base64 +B1Prn3sEdCnZQCgyR5r9g Base64 -B1Prn3sEdCnZQCgyR5r9g Base64 y0pEfbrg3S1bOF1VmGtfxV Base85 {-iekEE4M)R!2>3:Stl> Encoding Output UUID-NCName-32 b7aou7lt55qoqoziauder427wk UUID-NCName-58 B7wc88dU4e3NyJEj3e944DK UUID-NCName-64 B-B1Prn3sHQdlAKDJHmv2K N8JYxDHbz7rx9rGIw80uxC

NIL UUID Encoding Variant RFC9562, Section 5.9 Base16 00000000-0000-0000-0000-000000000000 Base16 00000000000000000000000000000000 Base32 AAAAAAAAAAAAAAAAAAAAAAAAAA Base32 00000000000000000000000000 Base32 00000000000000000000000000 Base36 --- 0 Base52 --- A Base58 1 Base62 0 Base62 0 Base64 AAAAAAAAAAAAAAAAAAAAAA Base64 AAAAAAAAAAAAAAAAAAAAAA Base64 ---------------------- Base85 00000000000000000000 Encoding Output UUID-NCName-32 aaaaaaaaaaaaaaaaaaaaaaaaaa UUID-NCName-58 A111111111111111______A UUID-NCName-64 AAAAAAAAAAAAAAAAAAAAAA Fa84QWiAxLXUJaHZmEVPEG

MAX UUID Encoding Variant RFC9562, Section 5.10 Base16 FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF Base16 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF Base32 77777777777777777777777774 Base32 VVVVVVVVVVVVVVVVVVVVVVVVVS Base32 ZZZZZZZZZZZZZZZZZZZZZZZZZW Base36 --- p777777777777777777777777p Base52 --- GBIWTpZqojFGQPQPXtvbJAv Base58 P8AQGAut7N92awznwCnjuQP Base62 HxECNQWFdpvuJxIw3HPrmH Base62 7n42DGM5Tflk9n8mt7Fhc7 Base64 /////////////////////w Base64 _____________________w Base64 zzzzzzzzzzzzzzzzzzzzzk Base85 s8W-!s8W-!s8W-!s8W-! Encoding Output UUID-NCName-32 p777777777777777777777777p UUID-NCName-58 P8AQGAut7N92awznwCnjuQP UUID-NCName-64 P____________________P NNC6dn4GR1JETNQMfLl6qN

UUIDv1 Encoding Variant RFC9562, Section A.1 Base16 C232AB00-9414-11EC-B3C8-9F6BDECED846 Base16 C232AB00941411ECB3C89F6BDECED846 Base32 YIZKWAEUCQI6ZM6IT5V55TWYIY Base32 O8PAM04K2G8UPCU8JTLTTJMO8O Base32 R8SAP04M2G8YSCY8KXNXXKPR8R Base36 --- BHW3F9QSZLQPYH8GTZ35HZ4UE Base52 --- EddHArfCMSZGGUJvWdXrHHq Base58 Qys2KsgsAKw9ZKupo76FCh Base62 F4bpVC8trxK13yapr3UFrY Base62 5uRfL2yjhnArtoQfhtK5hO Base64 wjKrAJQUEeyzyJ9r3s7YRg Base64 wjKrAJQUEeyzyJ9r3s7YRg Base64 kY9f-8FJ3Tmnm8xfrgvNGV Base85 .znd(LOs.@V=F+O?P<+y Encoding Output UUID-NCName-32 byizkwaeucqpmhse7nppm5wcgl UUID-NCName-58 B6S7oX73gv2Y1iTENdXX8hL UUID-NCName-64 BwjKrAJQUHsPIn2vezthGL LUZjlZguf8iMDOiFU7pUve

UUIDv2 Encoding Variant DCE Security UUID Base16 000003e8-cbb9-21ea-b201-00045a86c8a1 Base16 000003e8cbb921eab20100045a86c8a1 Base32 AAAAH2GLXEQ6VMQBAACFVBWIUE Base32 00007Q6BN4GULCG10025L1M8K4 Base32 00007T6BQ4GYNCG10025N1P8M4 Base36 --- 5XJERAFS5KNNNG5WAM10H Base52 --- KNcIMemTgumAjqCSfqp Base58 2SMnXSegyRgxWPnMoHS Base62 azPmOJmh9xNaNgM2sh Base62 azPmOJmh9xNaNgM2sh Base64 AAAD6Mu5IeqyAQAEWobIoQ Base64 AAAD6Mu5IeqyAQAEWobIoQ Base64 ---2uBit7Tem-F-3LcQ7cF Base85 000b++EF!YVh<}dt87a( Encoding Output UUID-NCName-32 caaaah2glxepkeaiaarninsfbl UUID-NCName-58 C11KtP6Y9P3rRkvh2N1e__L UUID-NCName-64 CAAAD6Mu5HqIBAARahsihL Fa84rLxnBVA2JNUzzkiHwn

UUIDv3 Encoding Variant RFC9562, Section A.2 Base16 5df41881-3aed-3515-88a7-2f4a814cf09e Base16 5df418813aed351588a72f4a814cf09e Base32 LX2BRAJ25U2RLCFHF5FICTHQTY Base32 BNQ1H09QTKQHB2575T582J7GJO Base32 BQT1H09TXMTHB2575X582K7GKR Base36 --- 5K8PHACEYCDEGBDB1VWP0EAHQ Base52 --- CKwZBXIbBzTOnGTcpOSLRtq Base58 CbuPE286MB6RsDazcU7sUy Base62 C1Rz9EB7xwwtaBE3hssbl8 Base62 2rHpz41xnmmjQ14tXiiRby Base64 XfQYgTrtNRWIpy9KgUzwng Base64 XfQYgTrtNRWIpy9KgUzwng Base64 MUFNVIfhCGL7dmx9VJnkbV Base85 ?1\tb3ped>Lo2muJP>R) Encoding Output UUID-NCName-32 dlx2braj25vivrjzpjkauz4e6i UUID-NCName-58 D3dTNMAmevR4NFAakRDtLdI UUID-NCName-64 DXfQYgTrtUVinL0qBTPCeI IRPuPak8l8KDjbMTJxDqqE

UUIDv4 Encoding Variant RFC9562, Section A.3 Base16 919108f7-52d1-4320-9bac-f847db4148a8 Base16 919108f752d143209bacf847db4148a8 Base32 SGIQR52S2FBSBG5M7BD5WQKIVA Base32 I68GHTQIQ51I16TCV13TMGA8L0 Base32 J68GHXTJT51J16XCZ13XPGA8N0 Base36 --- 8M8SCPFUGFIJ4QENJ0IG77QG8 Base52 --- DWDhSoKPZRoqkgBWaJcOckY Base58 JyZVoFVQxQNmw2bsgr7D1R Base62 EaqKcHGnV4iQSYo57bXn6o Base62 2rHpz41xnmmjQ14tXiiRby Base64 kZEI91LRQyCbrPhH20FIqA Base64 kZEI91LRQyCbrPhH20FIqA Base64 ZO37xpAGFm1QfEW6qo47e- Base85 K=Y}zqQE&OO2(xP*D!xe Encoding Output UUID-NCName-32 esgiqr52s2ezaxlhyi7nucsfij UUID-NCName-58 E55CtqYNqva1mcmaa877eoJ UUID-NCName-64 EkZEI91LRMgus-EfbQUioJ K0oEsdooJG5kbywVjft3Au

UUIDv5 Encoding Variant RFC9562, Section A.4 Base16 2ed6657d-e927-568b-95e1-2665a8aea6a2 Base16 2ed6657de927568b95e12665a8aea6a2 Base32 F3LGK7PJE5LIXFPBEZS2RLVGUI Base32 5RB6AVF94TB8N5F14PIQHBL6K8 Base32 5VB6AZF94XB8Q5F14SJTHBN6M8 Base36 --- 2RTO2O5WTBFMSYWZX7KHQ1Z8I Base52 --- BFPTsrUJhwfXFHQeVflYshu Base58 6nTLogGvw2vmQjtATLqvLq Base62 BaXm0PEMkU5w7EKQaysNQO Base62 1QNcqF4CaKvmx4AGQoiDGE Base64 LtZlfeknVouV4SZlqK6mog Base64 LtZlfeknVouV4SZlqK6mog Base64 AhO_UTZbKciKsHO_e9uacV Base85 f4KPZ>{GI&MeK63Sii1( Encoding Output UUID-NCName-32 ff3lgk7pje5ullyjgmwuk5jvcj UUID-NCName-58 F2K15VFLUBD326h169SNPjJ UUID-NCName-64 FLtZlfeknaLXhJmWorqaiJ H0VhGlmNXgTHGeRqD3DcUU

UUIDv6 Encoding Variant RFC9562, Section A.5 Base16 1EC9414C-232A-6B00-B3C8-9F6BDECED846 Base16 1EC9414C232A6B00B3C89F6BDECED846 Base32 D3EUCTBDFJVQBM6IT5V55TWYIY Base32 3R4K2J1359LG1CU8JTLTTJMO8O Base32 3V4M2K1359NG1CY8KXNXXKPR8R Base36 --- 1TM3WVVTP7XVNZXA2TV43IJWM Base52 --- liRiaXmgJTfBQppyCovyGu Base58 4oVbpzb8BpnTH1mg11dmWd Base62 6FuGgfRpa7N6YbrlxT6FQ Base62 w5k6WVHfQxDwORhbnJw5G Base64 HslBTCMqawCzyJ9r3s7YRg Base64 HslBTCMqawCzyJ9r3s7YRg Base64 6g_0I1BePk1nm8xfrgvNGV Base85 9)3YwbpWEeV=F+O?P<+y Encoding Output UUID-NCName-32 gd3euctbdfkyahse7nppm5wcgl UUID-NCName-58 GrxRCnDiX4mxSq8bFQjT3_L UUID-NCName-64 GHslBTCMqsAPIn2vezthGL GWDoX3DScmUiFyjHO1pLJW

UUIDv7 Encoding Variant RFC9562, Section A.6 Base16 017F22E2-79B0-7CC3-98C4-DC0C0C07398F Base16 017F22E279B07CC398C4DC0C0C07398F Base32 AF7SFYTZWB6MHGGE3QGAYBZZR4 Base32 05VI5OJPM1UC7664RG60O1PPHS Base32 05ZJ5RKSP1YC7664VG60R1SSHW Base36 --- 36TWI214QWJ7MGSVQ83NM8WF Base52 --- BrKaFlCsyjaiCYuzuWvtun Base58 BihbxwwQ4NZZpKRH9JDCz Base62 CzFyajyRd5A9oiF8QCBUD Base62 2p5oQZoHTv0zeY5yG21K3 Base64 AX8i4nmwfMOYxNwMDAc5jw Base64 AX8i4nmwfMOYxNwMDAc5jw Base64 -MwXsbakUBDNlCkB2-RtYk Base85 0E(rMD9zXlN8E+*3<O!N Encoding Output UUID-NCName-32 haf7sfytzwdgdrrg4bqgaoompj UUID-NCName-58 H3RrXaX7uTM6qdwrXwpC6_J UUID-NCName-64 HAX8i4nmwzDjE3AwMBzmPJ FcxAExHzEpSVJEpfkUXQYJ

UUIDv8 Encoding Variant RFC9562, Section B.1 Base16 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0 Base16 2489E9AD2EE28E008EC932D5F69181C0 Base32 ESE6TLJO4KHABDWJGLK7NEMBYA Base32 4I4UJB9ESA7013M96BAVD4C1O0 Base32 4J4YKB9EWA7013P96BAZD4C1R0 Base36 --- 25VHD0YEN79F79OO0TV0BAE9S Base52 --- skNtHBdXlnQCRPhYqjxSkQ Base58 5WhDz2zW6g9mHu7EP9hoVq Base62 BG6ufXDWs4d4Dd5uoJIAi0 Base62 16wkVN3MiuTu3Tvke980Yq Base64 JInprS7ijgCOyTLV9pGBwA Base64 JInprS7ijgCOyTLV9pGBwA Base64 87bdfHvXYV1DmIAKxd50k- Base85 b-g=/f5?(>J(:6b{k%{w Encoding Output UUID-NCName-32 iese6tljo4lqa5sjs2x3jdaoai UUID-NCName-58 I22HpMAy5M181AjPFG7eLXI UUID-NCName-64 IJInprS7i4A7JMtX2kYHAI Gh4ovtlXgG1ON4DKQNdPn6 Encoding Variant RFC9562, Section B.2 Base16 5c146b14-3c52-8afd-938a-375d0df1fbf6 Base16 5c146b143c528afd938a375d0df1fbf6 Base32 LQKGWFB4KKFP3E4KG5OQ34P36Y Base32 BGA6M51SAA5FR4SA6TEGRSFRUO Base32 BGA6P51WAA5FV4WA6XEGVWFVYR Base36 --- 5G8XXKU1AQGT02ZJGR8PA3EUU Base52 --- CIhPGFswaUyeIiUVKFQScIW Base58 CNV2iY4mKiTS1uw8RxapEH Base62 CxumvfWqhqp4Kq4BkCGR1s Base62 2nkclVMgXgfuAgu1a26Hri Base64 XBRrFDxSiv2TijddDfH79g Base64 XBRrFDxSiv2TijddDfH79g Base64 M0Gf42lHXjqIXYSS2U6vxV Base85 tOH@/jw}7nLzRq84E%t? Encoding Output UUID-NCName-32 ilqkgwfb4kkx5hcrxlug7d67wj UUID-NCName-58 I3aR2J7aw1BJj4jJvfuWTXJ UUID-NCName-64 IXBRrFDxSr9OKN10N8fv2J INshC24rV2DOUHBbMGbh5y

Microsoft UUID The following UUID 00000013-0000-0000-c000-000000000000 is for Microsoft.Azure.Portal and ensures this specification also includes non IETF/DCE variants of UUIDs. Encoding Variant Microsoft.Azure.Portal Base16 00000013-0000-0000-c000-000000000000 Base16 0000001300000000C000000000000000 Base32 AAAAAEYAAAAABQAAAAAAAAAAAA Base32 000004O000001G000000000000 Base32 000004R000001G000000000000 Base36 --- 41Y09GGWTDKLN13WMO74 Base52 --- KGlWYrtEyPFBiZpPts Base58 2anhPihXPV7NXZKLC7 Base62 fjupi4ia0Gz3Pwu9y Base62 VZkfYuYQq6ptFmkzo Base64 AAAAEwAAAADAAAAAAAAAAA Base64 AAAAEwAAAADAAAAAAAAAAA Base64 ----3k----2----------- Base85 0000j00000ZYjum00000 Encoding Output UUID-NCName-32 aaaaaaeyaaaaaaaaaaaaaaaaam UUID-NCName-58 A111Mo9hVUdmNWqcCExF__M UUID-NCName-64 AAAAAEwAAAAAAAAAAAAAAM Fa84R2HvcuS2kQOPfUIAE4

Example UUID Base Encoding Tools, Libraries, and resources The following list of libraries, tools, code, packages and other resources is for illustrative and research purposes. Neither the authors or IETF endorse any of these libraries or guarantee their contents safe and harmless. Install, download or use this software at your own risk.

Base32, Base

Base32, Hex

Base32, Crockford

Base32, NCNAME

Base36

Base58

Base62

Base64

Base85

Contributors

brad@peabody.io