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), Base32 for Humans [Base32human] (formerly known as Douglas Crockford's Base32), 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 Base32 for Humans ([Base32human]) 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 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 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 ordered as A–Z0–9 would change sort order and is therefore uncommon.¶

Base36 also compresses leading null bytes (see Section 4.9) which may be desirable to further reduce the size of the encoded UUID.¶

Base36 is reasonably available (Section 4.10) but does not have concrete specifications outlined by a standards body.¶

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 leading null bytes (see Section 4.9) 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.¶

See Figure 4 for an example.¶

FraqvVvqUBoEOFXsPYOPwUm

3.4. Base58

Base58, used by [Base58btc] (and [Flickr]), 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 Padding Characters, and most implementations follow the same alphabet, with the [Base58xrp] variant being a notable exception.¶

Base58 also compresses leading null bytes (see Section 4.9) 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

Base62 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 a number of libraries or discussions specifically using Base62 for UUIDs.¶

[Base62ieee] (defined by the IEEE) is one implementation and [Base62sort] is a variant that preserves sort order. Both variants use the same set of 62 characters but in a different order: [Base62ieee] orders the alphabet as A–Za–z0–9 while [Base62sort] orders it as 0–9A–Za–z to preserve lexicographic sort order (see Table 1). Additionally, [Base62ieee] includes padding while [Base62sort] does not.¶

[Base62ieee] also compresses leading null bytes (see Section 4.9) 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, Base64url in [RFC4648], Section 5 and Base64sort ([Base64sort]) (also known as Base64lex).¶

Base64 is recommended when maximum compactness is desired without Compressing Characters. 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]).¶

Base64 alphabets enjoy widespread availability (Encoding Availability) and are far more common than Base32 as per an analysis of RFC4648 alphabet usage in the wild [RFC4648_Usage_Report].¶

See Figure 7 and Figure 8 for examples.¶

+B1Prn3sEdCnZQCgyR5r9g==

-B1Prn3sEdCnZQCgyR5r9g==

y0pEfbrg3S1bOF1VmGtfxV

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 (Special Characters), and provide the most compact textual representation among the alphabets discussed. Common variants include Z85, [RFC1924] Base85, and ASCII85.¶

Some Base85 variants include compression techniques for certain byte sequences (see Compressing Characters). Those techniques are not universal across all Base85 alphabets.¶

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

See Figure 10 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.¶

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

The general statement by the authors is as follows: there is no single correct choice to cover every scenario.¶

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

For example, Base64sort ([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 [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 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 [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 the 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 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.¶

Figure 11 illustrate the ordering trends for some common BaseXX Alphabets that adhere to the US-ASCII character set and their ordering of the various components.¶

- Base10:      0123456789
- Base32hex:   0123456789ABCDEFGHIJKLMNOPQRSTUV
- Base36:      0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
- Base62sort:  0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
- Base64sort: -0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz

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

4.9. 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 Section 4.2.¶

Base36, Base52, Base58, and A secure, lossless, and compressed Base62 encoding 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 standard implementations than Base32hex as per [RFC4648_Usage_Report] 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 [Base32human] or [Base64sort] 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.¶

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

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

Base64sort: -0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz
Base64uuid: $0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz

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

[Base32human]

Crockford, D. and K. Davis, "Base32 for Humans", April 2026, <https://github.com/douglascrockford/Base32>.

[Base58btc]

Bitcoin, "Bitcoin Base58 Implementation", commit fae71d3, November 2008, <https://github.com/bitcoin/bitcoin/blob/master/src/base58.cpp>.

[Base58xrp]

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

[Base62id]

Prokhorenko, S., "Base62id Encoding Specification for Binary UUIDs", April 2026, <https://github.com/sergeyprokhorenko/Base62id/>.

[Base62ieee]

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

[Base62sort]

Wu, P.-C., "A base62 transformation format of ISO 10646 for multilingual identifiers", August 2001, <https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.408>.

[Base64sort]

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

[Base64uuid]

Prokhorenko, S., "The Base64UUID Encoding and Choice of Encoding for UUID", April 2026, <https://github.com/sergeyprokhorenko/Base64UUID>.

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

[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/>.

[NCNAME]

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

[RFC1924]

Elz, R., "A Compact Representation of IPv6 Addresses", RFC 1924, DOI 10.17487/RFC1924, April 1996, <https://www.rfc-editor.org/rfc/rfc1924>.

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

[RFC4648_Usage_Report]

"RFC4648 Alphabet Usage Report", commit de0a2760, November 2025, <https://gitlab.com/julian.reschke/base-encodings-terminology/-/blob/main/classifcation.md?ref_type=heads>.

[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. UUIDv2

C.6. UUIDv3

C.7. UUIDv4

C.8. UUIDv5

C.9. UUIDv6

C.10. UUIDv7

C.11. UUIDv8

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

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
- https://grokipedia.com/page/Base62
- https://repost.aws/questions/QUPyiPyPsTTz6bnss1nQLoiQ/is-qldb-document-id-a-globally-unique-uuid
- https://hexdocs.pm/base62_uuid/readme.html
- https://github.com/lucasmichot/uuid62

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/