Significant changes to Kindle image requirements

Updated 31 May 2014:

Amazon have upped the maximum pixel limit again for ebook covers and are now asking for cover images to be “2820 pixels on the shortest side and 4500 pixels on the longest side” for best quality. Maximum file size is still 5MB. Minimum pixel dimensions for covers are 625 x 1000 pixels.

This new size strikes me as overkill. The highest resolution device that Kindle produces is 2560 pixels; why would Amazon want 4500 pixels? Your guess is as good as mine.

For internal images, the KDP site now says GIFs of up to 5MB are also now accepted and the previous warning about avoiding compression by Kindle has been removed (I guess Amazon worked out the bugs).

In fact, all previous guidelines regarding dimension minimums have been removed from the website, leaving the user with very little information to go by. For that reason I suggest you go with the bigger file and, if such is not available, that you follow the previous minimum dimension guidelines below.

In The Global Indie Author I write of Amazon’s desire for larger, uncompressed images due to Amazon’s ability to make different image sizes for delivery to different Kindle devices and apps. As also noted, I took a lot of flak for it from other coders. Well, with the release earlier this year (yes, I know, I’m a bit behind on my blog) of their latest Kindle Publishing Guidelines, Amazon has not only made their desire for larger images official, they’ve upped the ante again.

First, cover images: Amazon now wants the cover image to be 2560 pixels on the long side and saved at 350 ppi. Maximum file size is 5MB.

For internal images, Amazon now wants photographs as large as 5MB maximum, saved at 300 ppi, embedded into the file; these large images will be then be processed by Amazon into the various sizes for different devices. Publishers are charged a delivery fee based on the smaller-images file produced for older Kindle devices, not the larger-images file sent to, for example, an iPad.

(It is not explained why the cover image should be 350 ppi but the internal images 300 ppi, except perhaps the former is a typo? Unless the 350 ppi is to accommodate the Kindle  Fire HDX 8.9″ screen, which is 2560 pixels high and 339 ppi. But then why not ask for all images to be 350 ppi?)

For photographs, the previously recommended dimensions of 600 x 800 pixels are now the new minimum. However, that is a minimum and such a photograph would, at its native size, display at only 3.7″ on the 7″ Kindle Fire HD (216 ppi), 3.15″ on the 8.9″ Kindle Fire HD (254 ppi), and 3″ on an iPad3 (264 ppi). While this may seem adequate in some cases, one cannot code Kindle in such a way as to prevent it from upsampling the image to full screen unless you code the image to display either as a percentage of the screen or as a fixed pixel dimension; if neither code is present then Kindle will automatically display the image at 100% of the screen, with dreadful results on these higher resolution devices. (And the resolution of the Kindle Fire HDX devices is even higher: the 7” model is 323 ppi and the 8.9” is 339 ppi.)

The problem with coding an image to display at a percentage of the screen is that the percentage may not work well across devices: if you code a 600 x 800-pixel photograph to display at roughly 60% of the screen width in order to keep the Kindle HD devices (1280 and 1920 pixels high) or the iPad3 (2048 pixels high) from upsampling, this makes the pictures too small on older, smaller Kindle devices and in the computer apps, where you likely want the photo to display at 80% to 100% of the screen size.

My new recommendation then, is to use images of at least 1600 pixels on the long side and preferably no less than 2000 pixels, which is between 80% and 100% of the 8.9″ Kindle HD and iPad screens less margins. A photograph of 2000 pixels will experience no upsampling, while a 1600-pixel image will be upsampled only about 10%, well within safe limits to avoid image degradation. In smaller devices the images will simply be downsampled. If you are concerned about wide adoption of the Kindle HDX 8.9″ with its 2560 pixel screen, then definitely aim for 2000+ pixels.

The new publishing guidelines are vague as to what happens if your images are smaller than 600 x 800 pixels, only to say that your book may be rejected, and will certainly be rejected if it contains photographs smaller than 300 x 400 pixels.

If your images are in the 600 x 800-pixel range, I would code in the pixel dimensions to prevent upsampling; the images will display at or near their full size on all devices; the images will just display smaller on the higher resolution devices. I think this the lesser of two evils: better to have smaller but sharper images than larger pixellated images.

For charts and tables and simple graphics, Amazon still wants these embedded as GIFs. GIFs, however, must be optimized down to 127KB prior to insertion into your document, as compression by Kindlegen is “best avoided.” Maximum size is 500 x 600 pixels, and if the graphic contains text, the lower case a must be no less than 6 pixels high.

If submitting your file to Amazon as an ePub*, total file size should not exceed 650MB. A word of warning to those with a large file: conversion of your HTML or epub file by Kindlegen into a mobi file prior to upload to Amazon is not recommended since doing so doubles the file size: Kindlegen embeds both a mobi7 and mobi8 version into the resulting mobi file. Creating a mobi file before uploading offers you nothing more than uploading the ePub directly to Amazon, and will only dramatically increase the time it takes you to upload your file to your dashboard and for Amazon to convert it before offering you a preview.

Note as well that the preview you can download from your dashboard does not yet have the image conversion/compression enacted and so the file size will be the same as the mobi file you uploaded, or approximately twice the file size of the ePub if you upload that format. Thus, these huge preview files are not appropriate for use as an advanced review copy.

(*Authors who elect to upload an ePub file for conversion should first amend the code as necessary for proper display in Kindle; this includes different image and font handling, and the guide items need to be added.)

 

Share this!

Leave a Reply

Your email address will not be published. Required fields are marked *