Rejoice! Kindle Previewer v2.91 Improves Ebooks for iOS

Expert publishing blog opinions are solely those of the blogger and not necessarily endorsed by DBW.

One valuable tool for ebook developers is Kindle Previewer (KP), a free utility Amazon provides that allows us to proof ebooks for the Kindle platform. Amazon recently released an update for the utility (version 2.91) and I’ve been able to do some light testing to find differences between the versions. When it came to accented content — namely, sidebars — I immediately discerned a difference in how an ebook rendered in Kindle for iPad, which I hope to illustrate in this post.

The previous version of KP rendered Kindle/Mobi files very poorly for Apple iOS devices (iPad and iPhone). For many of our titles, we include fallback CSS for ebooks rendered in Mobi7 — that is, when they’re read on “old-school” Kindles such as the DX and devices pre-Kindle Touch. However, for whatever reason, the same ebook would preserve such treatment on an iOS device — even though logistically, it should have interpreted more advanced aspects of the code, as KF8 does.

An example of this can be seen in this proof copy of Knock ‘em Dead 2014 (which you can preorder on Amazon).

Here is a Mobi file generated in KP v2.9 (click to enlarge this and all following screenshots):

iOS preview in KP v2.9

For our sidebars, we have some simple CSS (specifically, media queries) that do the following (for Mobi7 files):

  • Display “hidden” <hr /> rules
  • Hide background colors of a sidebar

The CSS to do this is

@media amzn-mobi {

hr {
div.sidebar {
 margin-top: 1em;
 margin-bottom: 1em;
 padding-left: 1.0em;
 padding-right: 1.0em;
 page-break-inside: avoid;


The hidden <hr />’s are utilized in order to differentiate the sidebar from the running text because of Mobi7’s shortcomings. If the background color is left on the <div> for the sidebar, the background color will render on iOS — but not on Kindle DX or older generation Kindles. However, the background color is rendered poorly, as seen in the screenshot below.

iOS preview in KP 2.91, with background-color: property preservedYeah, not the loveliest of pages, right? A good chunk of CSS outside the media query is ignored, such as margin, padding, and even the <hr /> we seek to hide:

hr {
div.sidebar {
margin-top: 1em;
margin-bottom: 1em;
background-color: #E6E7E8;
padding-left: 1.0em;
padding-right: 1.0em;
page-break-inside: avoid;

For us on the F+W ebook team, we found it so bizarre to see such poor rendering in iOS. Ebooks on Kindle for iOS felt incredibly stunted, and we were oftentimes frustrated with our code. The media queries were a decent solution for our problem.

So why are we rejoicing?

What’s the good news? The future looks bright for our Kindle books going forward, thanks to the Kindle Previewer update. Check out how our ebook now looks on iOS (Kindle for iPad), after creating it in v2.91:

Kindle ebook preview in Kindle for iPad; file generated in KP v2.91

We have a beautiful rendering of our sidebar on Kindle for iPad; as you can see, it ignores our Mobi7-specific CSS. If we load the same ebook in KP 2.9, our original Mobi7 CSS is still executed successfully:

Mobi7 preview in KP v2.91

(Side note: In KP 2.91, the options for e-ink device previews drop to the Paperwhite and the Kindle DX; previously, you could check for the Paperwhite, the Kindle DX, and the regular Kindle.)

However, there’s always a caveat for our progress: we can no longer preview Mobi files directly within the Kindle Previewer app. In order to view what a customer would see when they read a book on an iOS Kindle app, we are forced to sideload a file to our devices manually. We are not reading a Mobi file here; the format is actually .azk:

Dialog box during .azk file generation in KP v2.91

It looks like the format is specifically for iOS. The release notes for Kindle Previewer details how to load the file for viewing. You can do this with any Mobi file you create, but keep in mind that Kindle ebooks produced only in KP v2.91 will render this more advanced code.

If you sideload the .mobi file made in KP v2.91 and do not generate an .azk file, you’ll have a stunted ebook in your Kindle for iOS apps:

Mobi file generated in KP v2.91 (not .azk)

Meanwhile, where a sideloaded Kindle ebook is stored has also been changed. The .azk file correctly stores an ebook under Books, instead of Docs:


Additionally, it seems that the .azk file is for previewing purposes only; that is, you don’t need to deliver separate .mobi and .azk files to Amazon for distribution.

Through this update, it looks like format fragmentation may begin to ease, at least with regard to Amazon. However, it must be said that Kindle QA practices, in light of this update, now require a device for proofing — a considerable investment for any ebook department at a publisher.

I encourage developers to obtain an iPad (at the very least) for QA purposes with regard to Kindle for iOS. Utilizing a device to proof ebooks on Kindle apps is now indispensable with this new update to Kindle Previewer.

I’ll keep testing and follow-up with any crucial updates. Have you tinkered with Kindle Previewer v2.91? What improvements have you found? Please let us know in the comments!

8 thoughts on “Rejoice! Kindle Previewer v2.91 Improves Ebooks for iOS

  1. Pingback: Faber Factory 2013 – Rejoice! Kindle Previewer v2.91 Improves Ebooks for iOS

  2. Pingback: Kindle Previewer v2.91 Improves Ebooks for iOS

  3. Michael W. Perry

    You and I live in different worlds. You’ve got the time and resources to explore the intricacies and quirks of various ereader platforms. I don’t. Here’s an illustration.

    Recently, I released a book about a time when I worked on the night-shift nursing staff at a top children’s hospital caring for kids with leukemia. With so many stories to tell, I turned to stock photo services and found an appropriate picture of a hospitalized child to open chapters. That adds immensely to the book.

    On iBooks, the result looks marvelous, large, sharp photos arranged just right. On the Kindle reader for my Mac and iPad the book looks awful. The pictures are hardly bigger than commemorative postage stamps. Of the Kindle versions I checked, only the b&w version on my Kindle 3 even looks OK.

    What can I do? I don’t have the time or skills to play with CSS like you do and, even if I did, the results aren’t likely to matter much. It’s built into the differing specs. Apple allows images up to 3 meg in size. Amazon insists they be under 127K. That meant that, for the latter, I had to massive crop and crank up the compression to painful levels.

    I’d love to be able to signal to readers that the iBookstore version is much better by pricing it well below that for the Kindle, but that could result in Amazon’s lawyers pouncing on me or, more likely, Amazon arbitrarily cutting both the price and the royalties they pay me. What we have doesn’t remotely resemble a free market and the DOJ’s meddling has only made matters worse.

    The reality is that Amazon doesn’t seem that committed to handling complex ebooks or making picture-rich books look attractive. I see that when I select various platforms in Kindle Previewer. Almost all make me want to vomit. And because it is committed to supporting so many platforms, it doesn’t seem to do them very well. Apple seems to have shown better sense by supporting only iOS devices and (soon) the latest version of OS X.

    Apple also didn’t make the business blunder Amazon made with the first Kindle. Apple doesn’t have to worry about the cost of file downloads. Most go through WiFi and when the download is cellular, the purchaser is paying. But Amazon is covering the cost of cellular downloads, which has two nasty results: 1. Those image size limitations and 2. Download fees to authors and publishers that no one else charges.

    I liked the format of that picture-rich ebook on iPads so much, I’m going to create more such books. But I’m frustrated with Amazon’s disinterest in quality or consistency, particularly in comparison to CreateSpace, which handles those picture as B&W in the print version quite well. At present, there’s seems little I can do but gripe and steer potential customers toward the iBooks version.

    And that touches on my perennial gripe about publishing ebooks. While the 70/20 ebook market split between Amazon and Apple does mean that there is competition of sorts, it doesn’t seem effective enough to influence how either behaves. Amazon still acts like it owns the market, dictating rules about pricing and royalties that serve its interests. Apple is doing little to expand where ebooks from the iBookstore can be read. It may be bringing out a reader for OS X Macs, but apparently only for those who have Macs running the soon-to-be latest version of OS X. My MacBook won’t do that and the same it true of much of my potential audience, particularly teens.

    One final note, those who want to see what I’m complaining about can download the samples of my book from Apple and Amazon. You can see the difference for yourself. And I’d be interested in knowing how the Kindle version looks on the Kindle Fire. I don’t have one to check.

    –Michael W. Perry, My Nights with Leukemia: Caring for Children with Cancer

  4. Pingback: Latest Kindle News | Rory's Product Reviews

  5. Pingback: Rejoice! Kindle Previewer v2.91 Improves Ebooks...

  6. Pingback: Latest Kindle News | Espreo Product Review

  7. Pingback: Kindle Paperwhite Gets Upgrade As Sales Of eReaders Keep Dropping | Charles Good Deals

  8. Dale DePriest

    The wiki at has my attempt to decode a AZK file. It is a totally new format based on JSON. The AZK is a zip container and can be opened easily but this inside is a mess. Some gzip files, some compiled files some still source files (probably could be removed to save space). But it can be figured out. I suspect Amazon is using this as a pilot toward a new non ePub format for many portable devices.




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