Is there a catch to Kindle’s new option to upload your ebook cover separately?

Update: Kindle promised me an answer to this question by March 25. So far, all I’ve received is their assurances they are “researching” the matter. Considering this is not a difficult question, one has to wonder what, if anything, Amazon is hiding. Will keep you all posted.

Recently, Kindle modified its system to allow authors to use their ebook’s product image, uploaded to Kindle upon entering one’s book details, optionally as also one’s cover inside the ebook itself. The Global Indie Author was updated to reflect this change. As written, this is preferable as there are now problems with the newer Kindles and Kindle for PC/Mac apps not reading the cover bookmark correctly (this way Kindle will add its own bookmark when it adds the cover to your ebook). If the cover is your only image, by not embedding your cover in your source document you also do not have to worry about having to create a zipped file for upload. The method also makes the same file more usable for generating ePubs since when creating these you add the cover at the conversion stage. By adding your cover at the upload stage to Kindle you also don’t have to worry about the 127KB limit since the Kindlegen software will compress or downsample as necessary.

You may also have noticed that Kindle has increased the maximum pixel length for said product/cover images from 1280 to 2000 pixels on the longest side. This, too, seems like an improvement.

However, I began to wonder if this new method, and the increase in pixel dimensions, would result in higher delivery fees. If you upload a 2000-pixel image as opposed to a 1280-pixel image, and use this larger image for your cover, the result could be a difference of almost a megabyte in your ebook, meaning an increase in the delivery fee of $0.15. I contacted Kindle Support and they confirmed this was the case.

Ouch. So, that’s the catch.

Or is it? To put it simply, I think Kindle Support gave me the wrong answer — certainly wouldn’t be the first time. The reason I think I received the wrong answer is because of the way in which Kindle’s plug-in for InDesign is designed.

Normally, one has to compress images to fit within the 127KB limit of the Kindle; if your images are larger than 127KB, Kindle will compress them to fit when converting your file to the Kindle format. However, with InDesign authors can “future proof” their ebooks by embedding larger images, and at the higher resolution of 300 ppi; when the mobi file is then built by InDesign, the mobi file will contain multiple versions of all image files, at different resolutions and therefore file sizes. Kindle then delivers the best file size to meet the specifications of the device the ebook is being sent to. The delivery fee is based on the smallest file size potentially sent to a consumer, even if a consumer is actually sent a larger ebook file. This method “future proofs” the files since the trend is toward higher resolution devices.

Consequently, when I saw that Amazon is now offering the option to use one’s product image, and had increased the image dimensions, it struck me that something similar may be happening: that Kindle might be storing multiple versions of the larger image file and sending a different file according to which device the file is being sent to. Since the majority of ebooks only contain a cover image, Kindle may be trying to future proof these ebooks similar to the way it is with ebooks made using InDesign.

However, on the Kindle website it still says the Kindle can only support images up to 127KB. Since the larger the source file the more compression would be required to shrink the file size down to 127KB, using these larger product images as your ebook cover would be counterintuitive: the image degradation could be horrendous. Thus again I would think Amazon is storing multiple image files made from the one file. In the alternative, Amazon might be storing the larger jpeg file for future use and reducing a copy down to 127KB for current device use. Either way, it would be hugely unfair to charge the author a delivery fee based on the full image size instead of 127 kilobytes.

Which led me to ask Kindle the following:

  1. When the author elects to use this new option to upload their cover jpeg and use this larger image as both the product image and the cover image inside the ebook, what exactly are you doing with the file? Are you creating multiple files from a single jpeg? Are you merely asking for a larger file to future proof, but reducing the cover image to fit current device restrictions? If the latter, are you downsampling or compressing or both in order to reduce the larger product image down to 127KB? Is the 127KB limit still in effect or only for older devices?
  2. How is the delivery charge calculated when an author uses this new option to add the cover at upload? Is it based on the total file size of the text document plus the uploaded cover/product image at full size? Or is it based on the smallest file potentially sent to the customer? I am asking this because Kindle Support tells me that if an author uses this new option they are charged a delivery fee based on a total of the file size of the text document plus the full size of the uploaded cover/product image.

I tried going straight to the programmers but they have bounced my query back to Kindle Support. Kindle Support in turn has asked for time to research this before they come back with a new answer. I’ll keep you posted.

Share this!

4 thoughts on “Is there a catch to Kindle’s new option to upload your ebook cover separately?”

  1. It’ll be interesting to see what their response will be. When I first asked the question I got a stock response about how larger files equal higher delivery fees and a spiel on calculating one’s fee. But it doesn’t make any sense to charge for the full cover file size if isn’t yet being used. Worse, if they are compressing these large files down to 127KB instead of downsampling, any author with a decent cover is not going to use this upload function, or will upload a smaller file.

Leave a Reply

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