Given the length of an unencoded string, what single formula reveals the length of that string after base-64 encoding?

Question

I am trying to ascertain if there is a standard arithmetical formula which, given the length of an unencoded string, will reveal the length of that string when it has been base-64 encoded.

Here is a list of strings and their base-64 encodings:

A : QQ==
AB : QUI=
ABC : QUJD
ABCD : QUJDRA==
ABCDE : QUJDREU=
ABCDEF : QUJDREVG
ABCDEFG : QUJDREVGRw==
ABCDEFGH : QUJDREVGR0g=
ABCDEFGHI : QUJDREVGR0hJ
ABCDEFGHIJ : QUJDREVGR0hJSg==
ABCDEFGHIJK : QUJDREVGR0hJSks=
ABCDEFGHIJKL : QUJDREVGR0hJSktM

Here are the string lengths of the original strings and the lengths of their base-64 encoded strings (not including the = signs sometimes appended to the end of the encoding):

1 : 2
2 : 3
3 : 4
4 : 6
5 : 7
6 : 8
7 : 10
8 : 11
9 : 12
10 : 14
11 : 15
12 : 16

What single formula, when applied to the numbers on the left, results in the numbers on the right?

Answer 1

Your question is muddled, because of the part where you say "not including the = signs sometimes appended to the end of the encoding".

I'm not saying the length of the non-= portion of a base64 encoding result is uninteresting -- perhaps you have valid reasons for wanting to know that.

But if you are trying to calculate, say, the storage needed for a base64 encoding result, you need to include storage for the = signs; a base64 result cannot be decoded without them. Observe:

echo -n 'ABCDE' | base64
QUJDREU=

$ echo -n 'QUJDREU=' | base64 --decode | od -c
0000000    A   B   C   D   E                                            

$ echo -n 'QUJDREU' | base64 --decode | od -c
0000000    A   B   C                                                    

NOTE #1 : It is possible to not store the =-signs, because it is possible to calculate when they are missing from a given base64 result; they don't strictly speaking need to be stored, but they do need to be supplied for the decoding operation. But then you'd need a custom decoding operation that first looks to see if the padding is missing. I wager that storing at worst 2 extra bytes is far less expensive than the hassle / complexity / unexpectedness of a custom base64 decoding function.

NOTE #2 : As per follow-up comments, some libraries have base64 functions that support missing padding. Treatment of padding is implementation-specific. In some contexts, padding is mandatory (per the relevant specs). Each of the following is a reasonable treatment of padding for any specific library:

1. implicit padding : assume padding characters for inputs whose length is one or two bytes short of a multiple of 4 bytes (note: 3 bytes short is still invalid, since base64 encoding can only be 0, 1, or 2 bytes short)

2. best-effort decoding : decode the longest portion of the input that is divisible by 4 bytes

3. assume truncation : reject as invalid an input whose length is not divisible by 4 bytes, on the assumption that this indicates an incomplete transmission

Again, which of these is most correct will depend upon the context in which the code in question is operating, and different library authors will make different determinations on this.

The answer from @Victor is the best answer; it is the most germane to the context of the question (Javascript), and considers the crucial bytes-vs-characters issue as well.

Answer 2

Function https://stackoverflow.com/a/57945696/230983 does exactly what Rounin needs. But if you want to support Unicode characters you cannot rely on the length method, so you need something else to count the number of bytes. A simple way to solve this is to use blobs:

/**
 * Guess the number of Base64 characters required by specified string
 *
 * @param {String} str
 * @returns {Number}
 */
function detectB64CharsLength(str) {
  const blob = new Blob([str]);
  return Math.ceil(blob.size * (4 / 3))
}

/**
 * A dirty hack for encoding Unicode characters to Base64
 * 
 * @link https://developer.mozilla.org/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding#The_Unicode_Problem
 * @param {String} data
 * @returns {String}
 */
function utoa(data) {
  return btoa(unescape(encodeURIComponent(data)));
}

// Run some tests and make sure everything is ok
['a', 'ab', 'ββ', ''].map(v => {
  console.log(v, detectB64CharsLength(v), utoa(v));
});

Answer 3

As I was finishing typing out the question above, I realised (I think) what the formula is.

1. Divide the original string length by 3.
2. Round up that new number
3. Add the rounded up new number to the original string length

Like this:

getLengthOfStringAfterBase64Encoding = (string) => {

  const stringLength = string.length;

  const base64EncodedStringLength = stringLength + Math.ceil(stringLength / 3);

  return base64EncodedStringLength;

}