Formatting displayed incorrectly in Kindle KF8/Mobi files when side-loaded onto iPhone

I have noticed a problem with the formatting in ebook files that I have created in the Kindle KF8/Mobi format when they are loaded into the Kindle iPhone app (version 6.9.1) via email (i.e. not downloaded directly from the Kindle store). Chapter titles are not formatted correctly, images don’t seem to be sized properly, and, most significantly for readability, paragraphs are not indented on the first line. Here are some screenshots that show what I mean. This is from the book as published on Amazon, and shows the correct formatting for the beginning of a chapter:

This is the same file side-loaded onto the same phone:

This is how the paragraphs throughout the book appear when the file is side-loaded. When it is published on Amazon, they are indented normally:

I have tested the files on a Kindle Paperwhite, and I don’t see the problem there, nor does it appear in the Kindle app on my Mac. I wouldn’t be concerned about it, except that I send out advance copies of my books to reviewers, who might well be reading on their phones, and I would hate for them to have to deal with bad formatting. I love the control Scrivener gives me over formatting my ebook files, and I don’t want to have to switch to another piece of software.

Thanks for everything you do, and for any help you may be able to offer!

If the same file displays differently on different Kindle devices, that’s an Amazon issue, not anything that Scrivener can control.


I don’t see this problem with files that were not created in Scrivener, no matter how they are loaded into the Kindle app, so doesn’t that suggest it’s a problem with the files compiled by Scrivener?

Scrivener creates an ePub file. Then it invokes Amazon software to create a mobi file, which is then viewed using more Amazon software. How does the ePub file behave if you view it with tools like Adobe Digital Editions?


Thanks for replying, Katherine. The epub looks great in iBooks on the phone, and like a dog’s breakfast in Adobe Digital Editions, but in a completely different way that doesn’t really shed light on the problem. :unamused:

So if I understand what you’re saying, the problem is being introduced by the KindleGen software that is external to Scrivener? And maybe it’s somehow corrected during the publishing process on KDP, so that the published files look fine?

Ebook files are essentially HTML styled by CSS. If the book looks right on some devices but not others, then this generally means that there is nothing wrong with the file, but that that some devices just do not support some of the CSS settings. In this case, it looks as though the iPhone app is ignoring the CSS used to add borders to the title, the image size commands, and paragraph indent commands. This suggests that Amazon’s iPhone app has not been updated to support the CSS that other Kindle devices support.

All the best,

I recently came across this problem in our email tech support, and it turns out this (and potentially other CSS-related issues) are a known issue with the .mobi files KindleGen creates, and Amazon’s iOS mobile apps.

There is thankfully a simple solution, and that is to load the .mobi into Kindle Previewer 3. You will note that it takes a little while to load the file, claiming to be “Converting your book to kindle format”, which is a bit weird since Mobi is a Kindle format. But what it is doing is generating an AZK file on the fly, which it will use internally when previewing tablet and phone devices in the software. That’s the file you need to put on your devices, not the Mobi.

To get it out of Kindle Previewer, hit ⌘X or use File ▸ Export…, and save the file using the “Books - for side-loading to iOS devices (*.azk)” file format.

As for KDP, continue using the Mobi file as compiled out of Scrivener. The problem mainly has to do with that .mobi file being tuned for KDP upload, rather than being read like a normal book on devices directly.

Interesting! Thanks, Ioa. Funny how Amazon’s page says that AZK should only be needed for older iPhone devices: … 1000765261

I don’t quite understand it either, as I thought one of their more recent iOS app updates was to finally bring its KF8 rendering up to snuff, but maybe it has less to do with that and more to do with its inability get the right data out of the Mobi bundle format, it’s almost like it is opening the legacy MobiPocket part of the bundle, but with our modern CSS that doesn’t work so well with the old engine. Whatever the case the results are clear: use .mobi and it doesn’t look right on Apple equipment; use .azk and all is well.

Par for the course with Amazon though. For how nicely designed their actual hardware readers are, it’s like an entirely different company handles the publisher side of things. Look Inside does one thing, iOS another, Kindles yet another, a file format you aren’t supposed to use directly to test with but is the format you publish with (??)… and all the while I just can’t stop thinking: adopt ePub already. :mrgreen:

I’m having the same problem when I view the .mobi file on my iPad.
The same solution works for me. But it only works if I transfer the .azk file using iTunes. When I opened it in Dropbox and then exported it to the Kindle app, I got a “can’t be opened” error message.

I ran into a similar problem as well when I was testing this before (I was trying to AirDrop the file directly from the Mac to the iPad). It looks like Amazon has not programmed their iOS app to recognise “azk” as a file extension that it handles, so they are being very literal: you have to “side load” this file in the traditional sense, directly into its storage area.

Ah ha! I’m having the same problem with indents. I found the information in this set of posts very helpful.

My problem arose when I compiled my client’s manuscript (after importing it from Word) into a MOBI file for the first time in Scrivener 3, and shock horror, when viewed on my iPad via the Kindle App, the indents disappeared. I used the “as is” formatting option in Scrivener and at first I thought I had misunderstood how to use the “as is” option, having had no problems previously with Scrivener 2, so I went back and fiddled around, and fiddled around, compiled again. But shock horror the MOBI file was still not displaying indents on my Apple Mini iPad, nor on my Apple iPhone 6. So, being a fortunate person with lots of equipment, I had a look at the file via my iMac Kindle App, and there were my indents, displayed in all their beauty. WHAT! So then I loaded my file into my Kindle Touch, and there they were, displayed correctly again. And then … I loaded them into my Kindle Fire, and it too displayed the indents correctly.

Thank you fellow Scrivener users, for this set of post on this topic. Although I’m still stuck with the problem at least I know why there’s a problem, and will not have to compile over and over again thinking it’s me. I’ll work through your solutions, and hope it doesn’t take days to get my indents showing on my iPad via the Kindle App.

As per my earlier post, I’ve been seeking a solution to the known problem of some formatting disappearing when viewed on and Apple iPhone 6 Kindle App, and my iPad Mini Kindle App, after compiling to a MOBI file in Scrivener 3. I believe this problem is occurring because the KindleGen program not being as up-to-date with the Scrivener 3 compiler’s CSS when compiling to a MOBI file. I’ve gleaned that possibility from other posts in this forum.

For me, the formatting problem related to indents. My client’s manuscript’s paragraph indents had disappeared. So … taking on board the information regarding the KIndleGen problem, I found a work around. This is what I did. I imported a fully formatted Word File into Scrivener 3, I compiled it “as is”, and compiled it as an ePub (although I wanted a MOBI). Then, I took the ePub file and pulled it into Calibre (eBook software available free on the internet) where I converted it to a MOBI. Then, uploaded it to my Amazon Documents at, Then, I viewed it on several devices being my iMac Kindle App, my iPhone 6 Kindle App, my Mini iPad Kindle App, my Kindle Fire, and my Kindle Touch. All devices are now showing the correctly formatted indents.

I’m assuming the Calibre software has stripped out some coding, or replaced some. I’m not an expert, so I can’t be sure what the software did to fix the indent problem. Eventually, I know that either KindleGen 2.9 will be upgraded to match the most recent CSS used by Scrivener 3, but in the meantime the above work-around gave me a temporary solution.

I hope this post helps someone else.

Let’s hope that Amazon updates their Kindle Gen 2.9 soon, because I love Scrivener 3 and it’s such a nuisance to go out of it, and use an additional piece of software.

I think it has more to do with how Amazon has been very slow to adopt their newer standards on iOS. It took them forever to get the modern KF8 format working with it, and it seems instead of working toward full compatibility between platforms, they’ve opted to yet another format that only works with Apple devices.

KindleGen itself and Scrivener should be just fine, including with its newer CSS. We have tested all of the CSS that we use, as well as cross-references with Amazon’s documentation on what is acceptable. If you drop a compiled .mobi file into Kindle Previewer, it should look fine. It’s just when you try to put that .mobi file into a reader that doesn’t know how to handle it that you’ll run into issues.

It might have to do with the original source material. How are indents done in the document? If you turn on invisible characters, with View ▸ Text Editing ▸ Show Invisibles, do you see little arrows in front of each paragraph? If so the author manually pressed the Tab key in front of every paragraph. That’s something that should be fixed, as it’s no good for word processing in general (it only looks good, some of the time), and is directly incompatible with HTML-based formats, where tabs aren’t naturally handled in the output. In some readers, like older Nooks and Kobos, they can even mess up formatting entirely.

If that is the problem, there is the Edit ▸ Text Tidying ▸ Stip Leading Tabs menu command, which of course should be followed up with reformatting the text to have natural indents.

And if that is the problem, it may be Calibre converted these tabs into something more compatible with HTML. It may have done other things as well depending on your settings. It’s important to note that the .mobi file KindleGen creates is not a format for readers, but a format for publishing. Amazon does not expect it to work properly in their readers. When people buy the book, they are not downloading that .mobi file, but data extracted from it (like the properly formatted iOS version). So Calibre might have created a different type of .mobi file that is more suitable for reading.

In short: lost formatting when loading a KindleGen .mobi file on iOS is expected behaviour, and the only software that is fully programmed to load that file correctly (other than the KDP servers) is Kindle Previewer (which should be pretty accurate). So for proofing on devices, Calibre might be a better intermediate to work from, particularly since it can manage devices directly when they are plugged in, and can make intelligent conversions when uploading the book to them.

Thank you AmberV for taking the time to assist.

The the indents in my manuscript were created by a styling preset within Word. I’ll have a look at how the style was created and see if there’s another way to indent within Word.

I found the information you provided very interesting and helpful . Much appreciated.

Amber V. I’ve just gone back to my manuscript in Scrivener and looked at the hidden para marks etc. The indents were created using the “Paragraph Indents” First Line 0.2 ins, (tabs weren’t used). Keep in mind, this problem didn’t occur in Scrivener 2.

When I compile for ePub, the file is perfect. When I compile and preview in Kindle, the indents have disappeared. Do you know of a fix for this?

1 Like

Any idea when this might be corrected? I’m having the same problem. I want to send Kindle files to some beta readers who don’t have the technical knowledge or hardware to “side load” files.

We wouldn’t know—you’d have to get in touch with Amazon support to see if they have any intention of fixing that, or if they even are aware of it being a problem.

I’ve reported the problem to Amazon. If and when I get a reply I"ll post it here.