> The base64 version will always be 1/3 longer than whatever you feed it.

when going from ascii to base64 (which is what php’s base64_encode() function is fixed to use as input) the output will be longer, and that’s what base64 is so commonly used for (to the point where base64 means ascii<->base64). ascii has an alphabet size of 128, base 64, an alphabet size of 64. because 128 is larger than 64, going from ascii to base 64 will yield longer output than the input.

even though base 64 is so often used to encode ascii, i’m not. ascii has nothing to do with what i’m doing (apart from i’m using ascii text to represent the hex data initially, and base 64 data can nicely be represented in ascii). i’m simply going from a base 16 encoding to a base 64 encoding – and the alphabet of the base 64 encoding i’m going to is the same alphabet as base64 when used to encode ascii.

have a look at AnthonySterling’s function. he’s got it right (although not tested fully but confirmed basically). this is absolutely correct as well:

the logarithm (which is the opposite/reverse of, to the power of) of 16^32 (which is the number of unique values 32 hex digit strings have), base 64, is 21.333333… so that means the output of a hex to base64 function whose input is a 32 character long hex string should be 22 base 64 digits long.

have a look at this, which i just found:

http://home1.paulschou.net/tools/xlate/

copy and paste the example hex data 14f45c3234cde9c27e81deabc6c6adbe into the hex box, click decode, and observe the data in the base64 box. it’s the same as the output from AnthonySterling’s function. without the ='s on the end (padding) it’s 22 characters long.