Do you have illustrations meant to fill the available viewing space on a Kindle page? If so, there are a couple of things you need to know:
- The dimensions of the viewable area on the Kindle device. Unlike a book cover, which fills the screen at 600 by 800 pixels, pages have margins on all four sides and a narrow location bar at the bottom, which takes up space. A caption also requires some vertical space.
- The dimensions of an image that will not trigger resizing by Amazon’s DTP (Digital Text Platform) or popular publishing applications, such as MobiPocketCreator or Kindlegen. Resizing reduces image quality. Increasing image size can result in visible pixelation. Reduction also degrades quality, but not as dramatically.
Amazon’s formatting guidelines used to recommend that large images be 450 pixels by 550 pixels, and the DTP Forums will repeat that advice and provide conflicting answers. Images made at 450 by 550 pixels will not fill the viewable area. Images at 600 by 800 pixels are perfect for the cover image, but are bigger than the viewable area. They will be compressed to fit, but zoom nicely when clicked.
The latest Publishing Guidelines state that 500 by 600 pixels is the maximum size. The Images formatting guide says nothing at all about dimensions, but says: “An HTML image with an aspect ratio of 9 to 11 automatically displays with maximum screen coverage.” It’s enough to make your brain itch!
Dimensions that fill most of the screen and do not trigger resizing are close to, but not exactly, 500 by 600 pixels. A more accurate demonstration of what actually works is shown for Kindle 1 and Kindle 2 devices by Joshua Tallent, in Kindle Formatting: The Complete Guide. I’ve created similar test images for Kindle New Generation, and the results show that his recommendation for Kindle 2 works for Kindle New Generation, as well. However, I think it’s possible to use an image a few pixels larger with an acceptable, and very slight, decrease in quality.
Be aware that on the Kindle Previewer, the optimal dimensions that Tallent advises for Kindle 2 (520px by 622px) are the only ones that displayed perfectly. Images that deviate even a couple of pixels display distortion or banding with test images. Nevertheless, they displayed very well on the Kindle device itself, and look good when clicked to “zoom” in. The discrepancy is surely due to the difference in resolution between a computer screen (96ppi) and the Kindle New Generation eReader (167ppi). Kindle for PC is, by necessity, the same resolution as a computer screen. Therefore, images created at 167ppi look best in a window significantly larger than the Kindle reader screen. That’s good! You want a bigger reading area anyway, no?
I think the best way to get your head around image dimensions and decide what you want to do for your own illustrations is to see test images on your own Kindle, or in Kindle Previewer, if you don’t own a Kindle device. I’ve made a very short Kindle booklet with my test images that you may download (link below). See what you think!
Free Kindle Preview File
Download Kindle Maximum Image Size (PRC) (98KB). Save the file to your computer for viewing in Kindle Previewer or Kindle for PC.
To transfer the file to a Kindle device, connect the Kindle to your PC with the USB cable. In Windows, click the Start Button and then Computer. Find the drive letter assigned to the Kindle and expand it to see all the folders. Then drag the downloaded file from your Download folder into the Kindle Documents folder. The plus sign (+) indicates that a copy is being placed in the folder on the Kindle drive. Eject the Kindle. The booklet will be listed on your Home screen.
Excellent article and resource for a new user of Kindle who is trying to generate material for e-books. I was playing around with images but really needed exactly the information you provided. Many thanks
I’m so pleased it was helpful. Thanks for taking the time to let me know.
Very nice booklet. Thank you.
Have you done any playing around with file sizes? I see some comments about maximum file sizes of 64K and others of 127K. I have old grainy photos that look much better at larger sizes, at least before they can put on the Kindle.
Yes, I’ve experimented with file sizes and it’s absolutely true that images will be compressed in a noticeable way if they are over the file size limits.
If you use MobiPocketCreator, it will process images at or over 63KB to reduce file size. Kindlegen will process images at or over 127KB. Amazon’s KDP should honor the new 127KB threshold.
These programs reduce file size by compressing the images, which lowers quality. If you want MPC/Kindlegen/KDP to keep their mitts off your photos, make them fit the Kindle viewing area and save them “for the Web and devices” at a quality level that gets the file size under the limits.
So are the bottom line “rules”:
1. Maximum dimensions 520x622px
2. 167 ppi
3. 63KB max size with MPC; 127KB with Kindlegen
Thanks, in advance, for confirming!
In a sense, these 3 things are rules, but it’s often difficult to comply with all three at once. I keep images under the maximum file-size for Kindlegen, and at the maximum dimensions if meant to fill the viewing area.
I prefer to create images at 96ppi, which looks fine on both the Kindle device and the eReader apps. If an image has a small file-size, I might increase the ppi to 150 or to 167.
To avoid reprocessing, the dimensions seem to be the most important factor. Detailed photos that are very close to the max dimensions, but under the max file-size will still look fine. Banding in small graphic text will be more noticeable than in detailed photos.
If an image does not have the proper width-to-height ratio to fit the viewing area, I would crop it a little instead of resizing without constraints.
Amazon has conflicting information on the maximum file sizes. You may find 64/128KB in some places for MPC and Kindlegen, and 63/127KB in others.
Araby,
Thanks for such a quick reply.
From what I understand, the “rules” should be applied in the following order of precedence:
1. File size no larger than 63/127KB for MPC and Kindlegen respectively.
2. 167ppi maximum — if necessary, adjust down to 96ppi minimum to stay within file size limits and if possible, 520x622px dimensions.
3. If 63/127KB image can’t be produced using the minimum resolution of 96ppi, then the image dimensions will need to be reduced while maintaining the correct aspect ratio of 9:11.
I hate to beat a dead horse, but I would like to render these photos 1 time. To make matters worse, I just read on Amazon’s site that 300dpi is actually preferred in order to future-proof photos. That seems tough to accomplish and still have relatively large images within the maximum file size restrictions.
I guess I’ll have to break down and actually buy a KindleDX in order to physically see my results, as opposed to using the previewer on a PC!
Thanks again for any additional clarification. Truly appreciated.
The majority of Kindles in use are the 6-inch devices, not the Kindle DX, which has a resolution of 150ppi and a much bigger screen.
Those points are not so much rules as things to consider. The goal is to minimize the probability of full-viewing-area images being reprocessed.
Whoever wrote the original guidelines was unrealistic about using 300 dpi/ppi images under the suggested file size.
Hi Araby,
I’ve run a few test images through MPC and discovered that 622×520, 72ppi, 63KB jpgs look much better than ones at 96ppi. Less “jaggies”. At least that what I found when viewing with the Previewer.
Perhaps this is due to my viewing on a std PC?
What is your experience?
I’m guessing that because the 96ppi image file was much larger than 63KB, it is being resized by MPC and as a result, it suffers a loss in quality.
I can’t be much help with your question since I don’t use 72 ppi images for the Web or Kindle. MPC will always smush images with a file-size larger than its limit. Some colors produce more JPEG artifacts than others. Red is the worst.
Kindle Previewer for PC seems to render images for the Kindle device fairly accurately in grayscale. It works fine with books generated by Kindlegen.
You can also use MPC to get an OPF file for use with Kindlegen. Just make sure all your original book files are in the same folder(s) as they were for MPC and save a copy of the OPF file without any spaces in the filename. If there are spaces in the filename, Kindlegen will be unable to use it.
I think you’ll find that kindlegen will work on opf files that have spaces in the filename, you just have to put the filename in “double quotes”. Works fine for me.
Thanks for providing all the kindle info.
Thanks for taking the time. It’s so easy to overlook the obvious! I’ll make that correction.
I’m in the habit of never using spaces in file names when working with web-related files, databases, and eBooks, so I quickly jumped to the wrong conclusion with KG. I’m not changing my ways, because I think it’s a good habit. Nevertheless, I think most people do end up with spaces in their OPF file name and it’s easier to use quotes than rename the file. Thanks again!
I am hoping someone here can help me. I am getting a bit tired of the nonsense on the KDP forums where two bozos race to give any answer no matter how useless it is, just to keep their profile prevalent – they are obviously playing a cyber version of King of the Mountain.
Right, I have no problem with DPI or dimensions, per se, as they say. I am happy to use very low DPI if it is very low DPI which is needed (I currently have it at 111 DPI as this helps in keeping my full page images at the dimensions I need and at a low volume (they weigh in somewhere between 40 odd KBS to 80 odd KBS. However, despite using Kindle Page breaks before and after each full page image, whenever I have them centred, using the html center tag, a page break is forced after each one, ignoring the Kindle Page Breaks. Why is this? Does anyone know please? Plus – if not centred, but still full size, they do not force page breaks and just load and show as they should do. I am thinking aloud here really, but is it the centering process on KDP itself does not simply half the ever-present Kindle margin when centering, but adds more margin, which then takes a full size image at max size / dpi / dimensions – actually over that max?
J
I don’t know if this will help but here are a couple of things to check.
1. Include the width and height in the <img> tag. Image width and height should be 520px by 622px to avoid resizing (522px by 638px has also worked okay for me, and some people have reported using 525×640).
2. Enclose the image in a centered paragraph, which has no top margin. You can use a CSS style in your style sheet, the <p> tag. Alternatively, use the curious Kindle height=”0″ attribute in the <p> tag.
3. Include the Kindle pagebreak tag before and after the paragraph with the image (or image plus caption).
Here’s an example of an image with a caption, using the Kindle tags and attribute, and inline CSS:
<mbp:pagebreak/><p height="0" style="text-align: center; text-indent:
0;"><img src="images/wildcreatures-12.jpg" alt="" width="522" height="638" /><br /><small>Wild and shy and monstrous creatures ranged in her plains and
forests.</small></p>
<mbp:pagebreak/>
If you use a style sheet in the <head> of your HTML file, it would look something like this:
<style type="text/css">.center {text-align: center; text-indent: 0;}
p.center {margin-top: 0;}
</style>
And the HTML would look like this:
<mbp:pagebreak/><p class="center"><img src="images/wildcreatures-12.jpg" alt="" width="522" height="638" /><br /><small>Wild and shy and monstrous creatures ranged in her plains and forests.</small></p>
<mbp:pagebreak/>
Without a caption, it would be:
<mbp:pagebreak/><p class="center"><img src="images/wildcreatures-12.jpg" alt="" width="522" height="638" /></p>
<mbp:pagebreak/>
Here’s the image used in the example, if you want to play with it:
Do you have any information about childrens’ picture books for the Kindle, especially with the Kindle Fire now?
I still can’t decide if the best method is to have an image and then text underneath or to have one image, and put the text directly in the image. What is the best route to take? If the text is directly in the image, can the image be bigger than 520px by 622px?
I’m still confused! Thanks in advance.
Thank you, Araby. It would appear there are many things that Amazon / Kindle do not pass on / information they do not provide which very well should be. But the above you have done for me will I am sure help me to finally nail these problems. Cheers. J
Troy,
I don’t have any direct experience with childrens’ picture books for Kindle Fire, or for eInk Kindles. On older Kindles, where images are presented in a linear fashion along with text, there might be a problem with users changing the text size, bumping images to the adjacent acreens in an unpredictable way. In that situation, it would make sense to add text to an image if it’s critical that they be seen together on a single screen. Joshua Tallent’s article on picture books is informative.
With Kindle Fire, Amazon has announced that “fixed layouts” are possible, so that real text and images could be glued together on a single screen. See illustration on amazon.com.
It may also help to download a few book samples from Amazon and/or Barnes & Noble. Search for “picture books children” or “picture books children free” on their respective websites to find some. Quite a few kids’ books are meant to be read in landscape orientation.
The 520px x 622px size is recommended for Kindle 2 and Next Gen because it doesn’t trigger resizing and will display sharply. Images close to that size will be resized by the Kindle to fill the viewing area, with a small loss in quality. At that size, a two-line caption in small type will fit on the same screen. Not very applicable to childrens’ books, though.
There are a few discussions on the Amazon KDP forum about this, but folks there are usually committed to their own way of doing things, so you may find conflicting information. Amazon has published a list of supported HTML5 tags, but has not yet issued new Publishing Guidelines (past ver. 1.8), nor a Kindle Previewer (past ver. 1.6.1) that includes Kindle Fire.
Sorry I can’t be of more help. I would like to learn more about picture books, too.
For the new 6″ $79 model, I have done some testing with PDF.
I set my page size (in PDF XChange 4.0) to 4.799W 3.5H. Oh! notice I am pretending it is Landscape. The screen is actually 4.8 x 3.6, but with the stats at the (now) bottome, 3.6 won’t fit.
I am very happy that my music publishing program will take that page size, and makes a very nice booklet, printing with PDF XChange.
No conversions needed.
This is a really helpful discussion, now I guess, for backwards compatibility. Thanks so much. There is one thing I don’t understand though, and that is the role of dpi or ppi. If you have an image of a certain pixel size and file size, does changing only the dpi actually change the pixels in the file or just instructions for the output device (screen or printer) on how to scale the output?
I’ll admit couldn’t really see any difference between the 167ppi and 96ppi versions of a given image.
If you have two images that are 600×800 pixels, and one is 167ppi and the other, 96ppi, they will look identical on the same screen. Why? Because a pixel is a pixel and monitors display pixels and really don’t care about resolution. Conversely, if you edit an image that was created at 600x800px/96ppi and change it to 150ppi, without specifying width and height, pixel dimensions will increase to 938x1250px. If you check print-size in Photoshop, or print a copy from PS or a document, it will be bigger.
Thanks for the response! The first part of your answer reinforces my feeling that talk of dpi/ppi on the kindle is idle. What matters is pixel dimensions/file size.
Your test prc is a real eye-opener. Do you know if both dimensions have an effect? I’m particularly interested in images, like say dropcaps or short tables that are smaller the viewable area. I’d love to see or do some more tests with similar images for comparison. Is the test image available?
I guess the further question is how much any of this matters given KF8. But I suppose compatibility with all the old kindles is still important.
Yes, pretty much. Any image can be zoomed by selecting in the reader, so there’s some advantage of using a higher resolution when it’s really important (such as with a map that has tiny lettering), if you can keep the file-size down. (I’ve only bothered with this once, for a gray-scale line map saved as GIF, 16 shades of gray, 150ppi. When zoomed, it looked very clear. At viewing-area size, not quite as readable.)
Theoretically, dingbats or drop-caps shouldn’t be a problem if you include the dimensions in the img tag. If you don’t, they might quadruple in size unexpectedly. Joshua Tallent published some information on the points at which images trigger resizing to full-width or full-height. Lately, it seems that the safe dimensions are much less, and I’ve had images that should have been alright, blow up on-screen in Kindle 3, but not in Kindle Previewer.
You can make your own test grids by creating a file 525x640px, white background. Select some rectangular areas and fill some with black horizontal line patterns and others with black vertical line patterns, using the paint-can. Create whatever size images you want to test from this image. Save for web/devices as GIF or PNG. They will have very small file sizes, and don’t need to be perfect. but with straight lines, it’s easy to spot distortion.
HTML tables that fit within the viewing area display okay on newer kindles, but not Kindle 1. If too big to fit, an image is the best solution. To avoid problems with a short table presented as an image, it might be advisable to put it on a white background the width of the viewing area. User can zoom in to full-screen by selecting the image. If a table also approaches half the height, I would make an image that fills the viewing area. A short but wide table could be made into a rotated image that fits the screen vertically but is only as wide as it needs to be. Most people will rotate the screen clockwise to view a landscape image, so when creating the image, rotate it 90deg counter-clockwise.