For me, these are going to be special cases. There are likely to be other scenarios where Base64 encoded images are a smart approach.
Whether the gains for slow-changing data warrant the development effort is another matter. APIs delivering this type of data can easily be cached on a CDN and versioned to trigger updates. For example, loading partner logos, map pin images or category icons during app launch/restore. Also significant is that the use-case is centred around fetching images - in other words this isn’t for delivering images as part of a mixed content API.Īnother use could be delivering slow-changing non-personalised data that includes small images. Key to their approach is using chunked transfer encoding which effectively streams the response so the client can process the Base64 encoded images as they arrive across the wire. The argument is that when loading many small images, the overhead of HTTP requests becomes a factor. The Dropbox team make a compelling case for using Base64 encoding to effectively stream thumbnails for an image gallery. Does Base64 encoding images ever make sense on mobile? With cloud computing, file-based storage is very cheap and there might be a cost implication for taking a Base64 approach to images. If you are storing large volumes of images, then you are shifting a bulk of storage to a structured datastore (i.e. You will also need to watch for any adverse effects on database performance depending on your storage engine. This might require some custom logic that is hooked into your content management system. To create Base64 encoded representations there will probably need to be some post-processing following image upload. Most content management tools handle images as binary files.
BASE64 ENCODING SIZE INCREASE FOR ANDROID
However, if images are sent to the device as Base64 encoded strings every time within an API response, any caching capabilities on the device becomes irrelevant.Ĭaching on the device represents quite a major improvement for app performance, especially as app-level caching is very easy with mature libraries such as Picasso for Android ( ) or Kingfisher for iOS ( ). Typically apps will cache images so they must not be repeatedly re-fetched.
Image caching on the device is no longer possible. However, with dynamic APIs there is quite a bit of architectural complexity compared to delivering static assets such as images via a CDN. The whole API response must be delivered by CDN.Īn API caching strategy can be straightforward if the API is not dynamic, e.g. CDN caching is harder.Ĭontrary to image files, the Base64 strings inside an API response cannot be delivered via a CDN cache. The effect is a more responsive app that feels faster to users. This means users will see on-screen loading states for longer and the app will appear sluggish as users wait.Īlternatively, when an app loads images separately from the API payload, the app can show the data from the API and then progressively load the images. īy including all image data together in one API response, the app must receive all data before drawing anything on screen.
) User Experience is negatively impacted. However sizes will still be larger if the binary images are compressed. With gzip compression this bloat can be avoided if the alternative is raw binary images. Base64 images are bloated.Īs well as a larger overall payload size, the size of the Base64 encoded image is approximately 30% larger than the original binary image. Larger payloads also mean more time for responses to be in flight and more time for (mobile) network drops. Over mobile networks, additional payload sizes matter. API response payloads are large.īy including the data for every image in the API response, the response payloads started to get in the MB range. Here are the concerns we discussed which led the API to be changed to use URIs for images instead.Īt the end I consider a couple of cases where Base64 encoding could be a good option. Recently I came across an API from a client that delivered images in part of the response as Base64 encoded strings.