Yes but why represent data this way when HTTP can already handle binary? Does base64 actually compress binary data enough to make these optimized requests? I'm genuinely asking because I have not googled it yet.
Base64 doesn't compress at all, in fact it's only 75% as efficient as binary, meaning that encoding a file into Base64 increases its size by a third.
Base64 uses a 64 character alphabet (hence the name), so you can only represent 64 different values within each byte. 64 == 2^6, so basically you are using 6 bits out of every byte and losing the other 2 bits.
HTTP can use compression to reduce the size of the Base64 representation, but assuming the images were already using a compressed format, all this is going to do is mitigate the inefficiency, it's not going to be more efficient overall.
It's worth noting that for highly-compressible types of files, if you do need to use base64 for some reason it's still more space-efficient to compress first (before base64). If you can compress to 2/3 the size, base64 will only bring it back to the original size again.
This mainly applies when you have to transmit binary data using a text-based format like JSON or XML. I've also used this before to build a shell-script-based installer, where a compressed archive is base64'd in a variable.
Base64 uses a 64 character alphabet (hence the name), so you can only represent 64 different values within each byte. 64 == 2^6, so basically you are using 6 bits out of every byte and losing the other 2 bits.
HTTP can use compression to reduce the size of the Base64 representation, but assuming the images were already using a compressed format, all this is going to do is mitigate the inefficiency, it's not going to be more efficient overall.