The other day I finished my introduction post and today I thought I’d start a new series on “things I’ve learned” (or today I learned since it’s got a better ring to it).  As the project I’m working on has been gaining traction, there’s been a new initiative to embed the React application into other “parts” of the company. One of these highly dysfunctional parts is an outdated AngularJS application which just so happens I know almost nothing about. Having taken great pride in my own ability to deliver working applications I delivered the compressed js and css files to the Angular developer, even betting my own limb as an insurance policy in the process. To the disappointment of my own limb, the application worked fine except that none of the icons rendered. All that stood in the icon’s stead was the broken image reflecting the state of my pride in that very moment. This would ensue a long pointless journey to learn something that might never be of any use to me ever again. A long lesson about SVG and PNG and base64.


Having used FontAwesome‘s extensive icon library I knew it couldn’t be an issue on their end so it had to be something I was doing. I’d followed the steps on the React FontAwesome Github on how to build a library to reference icons in my app more conveniently. Clearly that wasn’t enough. I figured that using “npm run-script build” to package my application using webpack was leaving out an essential part of the application, the icons. This turned out to be true when I downloaded the icons directly from FontAwesome and included them as local imports out of an image folder. The icons were showing up again but another issue lied before me. How would I get my icons into the Angular developers “images” folder? In the corporate world things move slow and developers move even slower so I knew that simply sending over the images wouldn’t be a practical solution.


My boss who’s a senior developer then mentioned the alternative of encoding the images via base64 instead of sending the images over. It would allow me to essentially include any images/icons directly into the html and let the other developer’s code decode my images. (A modern day Trojan Horse if I’d ever seen one.) Turns out “base64-ing” your SVG images is not a great idea. It could end up actually taking more memory than the SVG itself.


(As a side note SVG is actually pretty cool tech. It stands for “Scalable Vector Graphics” and basically tells your browser exactly how to draw lines, shapes, etc. The downside is that since it’s complex formulas telling your browser what to draw, drawing multi-colored images is a bit tough. Read more about SVG here.)


Not to worry though a third-party SVG to PNG converter makes quick work of those pesky SVGs. Now, it finally looked like the table was set, the forks and knives were laid out, and the roast turkey was marinating center table. But when it was time to dig in, I noticed something very peculiar. All my icons that had decided to join me for dinner were wearing those fake glasses + nose + mustache combos. They were all fakes. None of them encoded. Why didn’t my PNGs encode to base64? I’ll tell you why. I will condense 4 hours of changing code, looking up StackOverflow, renaming variables, re-downloading images and various other attempts to fix it into one sweet solution:


The images were too big.


Don’t ask me how I figured that out because I think I tried every other possible thing to get it to work and I must have been dragging and dropping the images in the folder thinking I’d probably get fired soon when I accidentally opened up a picture editor and changed the pixels from the thousands to the hundreds. If there is any documentation online that tells you that this is the norm for how base64 works, then I haven’t found it. But at least you know now. I wouldn’t expect this WordPress to show up as a solution if you ever googled it but if my God’s grace you stumbled upon this and it saved you hours of time then kudos friend.


I might have lost a limb and some marbles but at least you won’t lose yours.