Trying to jam in the extra characters for "efficiency" also doesn't really do much. Base84 is 6.4 bits per character, base64 is a flat 6 bits per character, base58 is 5.86 bits per character. It may intuitively feel like having 26 more characters to encode with would be hugely more efficient but for the extra risk of what all those characters get us we're only getting just over .5 more bits per character. I need to be either pretty desperate for efficiency, rare in 2026, or very, very sure that those things are only going places where those characters aren't risky or inconvenient, which is pretty difficult to guarantee since even if it is in fact true today who's to say it will be tomorrow, for this to be worth the risk of the extra characters.
Even just the extra characters in base64 are often annoying and we already have multiple common base64 standards because even trying to find just two more characters to fill out a-zA-Z0-9 is hard.
> Trying to jam in the extra characters for "efficiency" also doesn't really do much. Base84 is 6.4 bits per character, base64 is a flat 6 bits per character, base58 is 5.86 bits per character.
Also on efficiency, you are trading off code complexity for a little extra storage: base64 is a nice round 6 bits per character meaning every three bytes encoded is four output. Neither base84 nor base58 align on convenient bit boundaries like that so choosing the output character is more faf. Padding could be more complicated too.
Now if you are looking at a per-character limit where the characters are multi-byte (say SSMS shortcuts which are limited to 32767 UCS2 characters) then some form of base4096 (12 bits per character so three 8-bit bytes to two output characters) might be useful. Yes, I have done this: putting a long analysis proc (a replacement for sp_help & friends) into a “shortcut” I was getting close to the 32K-char limit so compressed and base64ed the code and included an unpacker. This was more than enough to deal with the problem (TBH, just stripping comments would have done!) and simplified things in some ways as I no longer needed to escape quotes and such, but I went one step further played with writing a B4096 encoder because I like playing with that sort of silliness. I went with 4096 due to aligning nicely with 4-bit boundaries, and finding 4096 useable characters (avoiding control characters, undefined codes, and other unprintables) is easy. If the limit is actually 32767 or any Unicode characters (including those not in the UCS2 or UTF16 base plane set) then you could perhaps get even more daft though I'm pretty sure it is just 16-bit characters and not full Unicode.