Alternate UUID Encoding Methods

2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Abbreviations

The following abbreviations are used in this document:¶

UUID

Universally Unique Identifier [RFC9562]¶

BaseXX

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

3.1. 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 ([RFC4648], Section 6), Base32hex ([RFC4648], Section 7), Douglas Crockford's Base32 [DCB32], Z-Base-32 [ZB32], and [GEOHASH].¶

Base32 alphabets vary the most in character choice because implementers can be selective about which characters are included. Character Exclusions and alphabet ordering (see Sorting and Ordering) 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. Special Characters are rarely used with Base32, except for Padding Characters or Checksum Characters features, which can often be omitted.¶

Base32 is a strong choice when available. Base32hex ([RFC4648]) and Crockford's Base32 ([DCB32]) are recommended options for a 26-character UUID that works well for both machines and humans. See Figure 1 and Figure 2 for examples.¶

Z-Base-32 human-oriented base-32 encoding makes many changes to the underlying alphabet to accommodate a specific use case and is not recommended for UUIDs. Although [GEOHASH] is closer to Base32hex and excludes some characters like Crockford's 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 UUID Encoding Best Practices when selecting an alphabet not listed here.¶

V0EKVBJTTG8T19R502GCI7JBUO

Z0EMZBKXXG8X19V502GCJ7KBYR

3.2. 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 Case Sensitivity). Alphabet ordering matters: using an alphabet with ordered as A–Z0–9 would change sort order and is therefore uncommon.¶

Base36 also compresses nullish characters (see {(best_practice_compression}}) which may be desirable to further reduce the size of the encoded UUID.¶

Base36 is reasonably available (Section 4.10) but generally offers smaller benefits compared with base32hex or Crockford's Base32, so it is not recommended as a required encoding for all UUID implementations.¶

See Figure 3 for an example.¶

EOSWZOLG3BSX0ZN8OTQ1P8OOM

3.3. 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 (Special Characters) and excludes digits, avoiding issues with leading digits in some contexts. Its ordering can be chosen to preserve desirable sort behavior (see Sorting and Ordering).¶

Base52 also compresses nullish characters (see {(best_practice_compression}}) which may be desirable to further reduce the size of the encoded UUID.¶

See Figure 4 for an example.¶

FraqvVvqUBoEOFXsPYOPwUm

3.4. Base58

Base58, used by [Bitcoin] (and [Flickr]), is a popular alphabet similar to Crockford's Base32 in its character exclusions. Base58 encodes a 128-bit UUID into a 22-character string (about 5.857 bits per character). Base58 typically omits Padding Characters, and most implementations follow the same alphabet, with the [Base58xrp] variant being a notable exception.¶

Base58 also compresses nullish characters (see {(best_practice_compression}}) which may be desirable to further reduce the size of the encoded UUID.¶

Base58 Encoding Availability varies, but the format is well-known and commonly used for UUIDs in practice.¶

See Figure 5 for an example.¶

B7wc88dU4e3NyJEj3e944DK

3.5. Base62

[IEEEBase62] (defined by the IEEE) is the largest BaseXX alphabet that contains no special characters (Special Characters). Base62 encodes a 128-bit UUID as a 22-character string (about 5.954 bits per character). During research the authors observed few libraries or discussions specifically using Base62 for UUIDs.¶

Base62 also compresses nullish characters (see {(best_practice_compression}}) which may be desirable to further reduce the size of the encoded UUID.¶

See Figure 6 for an example.¶

HiLegqjbBwUc0Q8tJ3ffs6

3.6. Base64

Base64 alphabets require special characters (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 Usage when selecting an alphabet. The most common variants are the Base64 alphabet in [RFC4648], Section 4 and Base64url in [RFC4648], Section 5.¶

Base64 is recommended when maximum compactness is desired without {(best_practice_compression}}{: format="title"}. For most use cases, Base64url ([RFC4648], Section 5) is encouraged because it is safe for URLs, filenames and Application Specific use cases. When lexicographical sorting that matches binary order is critical (for example, with UUIDv6 or UUIDv7), consider Base64sort ([Base64sort]).¶

UUID implementers SHOULD implement Base64url because it already enjoys widespread availability (Encoding Availability).¶

See Figure 7 and Figure 8 for examples.¶

+B1Prn3sEdCnZQCgyR5r9g==

-B1Prn3sEdCnZQCgyR5r9g==

3.7. 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 (Section 4.5 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 Compressing Nullish Characters). Those techniques are not universal across all Base85 alphabets.¶

Z85 is the recommended Base85 variant for UUIDs when Base85 is desired.¶

See Figure 9 for an example.¶

{-iekEE4M)R!2>3:Stl>

4.1. 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: there is no single correct choice for every scenario.¶

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 [RFC9562]) 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 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.¶

4.2. Maximum Character Length

The number of characters 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 [RFC9562], Section 5.10.¶

Table 2 details the maximum length of various BaseXX Encoding methods with UUID MAX, without padding present.¶

4.3. 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.¶

Since UUIDs defined by [RFC9562] are always 128 bits, padding MAY be omitted and the resulting output will always be the same length.¶

Table 3 compares padding usage among the BaseXX encoding methods in this document.¶

4.4. 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.¶

Table 4 compares checksum usage among the BaseXX encoding methods in this document.¶

4.5. 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 [RFC4648] 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.¶

Table 5 compares special character inclusions among the BaseXX encoding methods in this document.¶

4.6. Character Exclusions

Newer BaseXX alphabet may exclude characters and keep only one value present.¶

This often occurs when multiple characters are similar in shape which 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 reasons. 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 [RFC4648], Section 7 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.¶

- 0, O, o
- 1, I, i, L, l
- 2, Z, z
- 5, S, s
- V, v, U, u

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.¶

Table 6 compares character exclusions among the BaseXX encoding methods in this document.¶

4.7. 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 Sorting and Ordering.¶

The BaseXX alphabet used also changes comparison logic: "aBc" does not necessarily equal "AbC" in all encodings.¶

Table 7 compares case sensitivity among the BaseXX encoding methods in this document.¶

4.8. 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 underlying algorithm.¶

The BaseXX alphabets generally consist of two or more of the following 4 components with optional omissions as defined by Section 4.6:¶

1. Numeric Characters: 0-9
2. Uppercase Character: A-Z
3. Lowercase Characters: a-z
4. Symbols: underscore (_), hyphen (-), plus (+), forward slash (/), dollar sign ($), etc.

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 ([RFC20]).¶

A common sorting example is a symbol like the dash (-) character may sort before numbers while other special 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 includes symbols.¶

Figure 10 illustrate the ordering trends for some common BaseXX Alphabets.¶

- Base10: 0123456789
- Base36: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
- Base62: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
- Base64: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_

Table 8 compares binary sorting among the BaseXX encoding methods in this document.¶

4.9. Compressing Nullish Characters

Some BaseXX alphabets may use varying techniques for compressing nullish characters which can sometimes yield values smaller than what is cited in Section 4.2.¶

Base36, Base52, Base58, Base62 will trim leading zero characters before attempting to encode the data.¶

Base85 alphabets may employ a technique to compress a continuous four byte sequence of ASCII Space characters as the character lowercase y.¶

Base85 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 Appendix C.2 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 Section 4.2.¶

4.10. 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 implementations than Base32hex while even fewer have implemented Base62 or even Crockford's Base32 variant.¶

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.¶

4.11. 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.¶

For reference Base02 uses 2 bits per character encoding while Base10 uses 4 bits per character and 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.¶

Table 9 compares bits per character among the BaseXX encoding methods in this document.¶

4.12. 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.¶

9.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

9.2. Informative References

[Base58xrp]

XRP Ledger, "base58 Encodings", 2024, <https://xrpl.org/docs/references/protocol/data-types/base58-encodings>.

[Base64sort]

Davis, K., "A Sortable Base64 Alphabet", December 2025, <https://github.com/kyzer-davis/base64-sort-ietf-draft>.

[Bitcoin]

Bitcoin, "A secure, lossless, and compressed Base62 encoding", commit fae71d3, November 2008, <https://github.com/bitcoin/bitcoin/blob/master/src/base58.cpp>.

[CSS]

W3C, "Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification", June 2011, <https://www.w3.org/TR/CSS2/syndata.html#value-def-identifier>.

[DCB32]

Crockford, D., "Douglas Crockford's Base32", November 2002, <https://www.crockford.com/base32.html>.

[Flickr]

Kellen, "manufacturing flic.kr style photo URLs", n.d., <https://www.flickr.com/groups/api/discuss/72157616713786392/>.

[GEOHASH]

Geohash, "Geohash", commit 3f0ce0b, November 2009, <https://github.com/vinsci/geohash/blob/master/Geohash/geohash.py>.

[HTML]

whatwg, "HTML Living Standard", November 2025, <https://html.spec.whatwg.org/>.

[IEEEBase62]

IEEE, "A secure, lossless, and compressed Base62 encoding", November 2008, <https://ieeexplore.ieee.org/document/4737287>.

[NCNAME]

Taylor, D., "Compact UUIDs for Constrained Grammars", September 2025, <https://datatracker.ietf.org/doc/draft-taylor-uuid-ncname/>.

[RFC20]

Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/rfc/rfc20>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC9499]

Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, <https://www.rfc-editor.org/rfc/rfc9499>.

[XML]

W3C, "Namespaces in XML 1.0 (Third Edition)", December 2009, <https://www.w3.org/TR/2009/REC-xml-names-20091208/>.

[Z85]

iMatix Corporation, "32/Z85", 2013, <https://rfc.zeromq.org/spec/32/>.

[ZB32]

O'Whielacronx, Z., "human-oriented base-32 encoding", November 2009, <https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt>.

C.1. Generic UUID

C.2. NIL UUID

C.3. MAX UUID

C.4. UUIDv1

C.5. UUIDv3

C.6. UUIDv4

C.7. UUIDv5

C.8. UUIDv6

C.9. UUIDv7

C.10. UUIDv8

D.1. Base32, Base

- https://github.com/chilts/sid
- https://www.jsdelivr.com/package/npm/uuid-encoder
- https://github.com/jetify-com/typeid
- https://docs.crunchybridge.com/api-concepts/eid
- https://hackage.haskell.org/package/ron-0.12/docs/RON-UUID.html
- https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abencl_system_uuid.htm

D.2. Base32, Hex

- https://github.com/rs/xid

D.3. Base32, Crockford

- https://github.com/ulid/spec
- https://codeberg.org/prettyid/python
- https://ptrchm.com/posts/based-uuid/
- https://github.com/martinheidegger/uuid-b32
- https://docs.rs/fast32/latest/fast32/
- https://uuid.ramsey.dev/en/stable/rfc4122/version7.html
- https://crates.io/crates/crockford-uuid
- https://rymc.io/blog/2024/uuidv7-typeids-in-diesel/
- https://docs.rs/rusty_ulid/latest/rusty_ulid/

D.4. Base32, NCNAME

- https://www.rubydoc.info/gems/uuid-ncname

D.5. Base36

- https://github.com/paralleldrive/cuid2
- https://www.jsdelivr.com/package/npm/uuid-encoder
- https://duncan99.wordpress.com/2013/01/22/converting-uuid-to-base36/
- https://github.com/salieri/uuid-encoder
- https://stackoverflow.com/questions/62059588/shortening-a-guid
- https://gist.github.com/fabiolimace/508dd2dd9d32fd493b31a5f386d5d4bc
- https://classic.yarnpkg.com/en/package/base36-uuid

D.6. Base58

- https://github.com/cbschuld/uuid-base58
- https://www.linkedin.com/pulse/advantages-using-base58-unique-identifier-databases-lucian-ivanov
- https://github.com/AlexanderMatveev/go-uuid-base58
- https://packagist.org/packages/cbschuld/php-uuid-base58
- https://classic.yarnpkg.com/en/package/uuid58
- https://blog.schochastics.net/posts/2024-08-24_short-uuids/
- https://www.jsdelivr.com/package/npm/uuid-encoder

D.7. Base62

- https://github.com/boundary/flake
- https://github.com/segmentio/ksuid
- https://www.jsdelivr.com/package/npm/uuid-encoder

D.8. Base64

- https://github.com/elastic/elasticsearch/blob/main/server/src/main/java/org/elasticsearch/common/UUIDs.java#L23
- https://github.com/chilts/sid
- https://github.com/twitter-archive/snowflake
- https://github.com/ppearcy/elasticflake/blob/master/src/main/java/org/limberware/elasticflake/Base64.java
- https://www.mongodb.com/docs/manual/reference/method/ObjectId.createFromBase64/
- https://firebase.blog/posts/2015/02/the-2120-ways-to-ensure-unique_68
- https://www.jsdelivr.com/package/npm/uuid-encoder
- https://base64-uuid.com/
- https://rcfed.com/Utilities/Base64GUID
- https://toolslick.com/conversion/data/guid
- https://guidgenerator.com/
- https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abencl_system_uuid.htm

D.9. Base85

- https://stackoverflow.com/a/772984
- http://codehardblog.azurewebsites.net/encoding-uuid-based-keys-to-save-memory/
- https://gist.github.com/Higgs1/fee62d230bd87257e0b0
- https://www.npmjs.com/package/pure-uuid
- https://cjhaas.com/2013/11/12/php-base85-encode-128-bit-integer-guiduuid/
- https://webpowered.tools/textcodec/