Pile On for Look Inside

I know I’m not the only one to have these problems with Amazon’s Look Inside, from what others have said here. But, to add to the fire, here’s my story…

I’m using Scrivener for Mac OSX 2.8.0, with KindleGen V2.9, on a mid-2012 rMBP running MacOS Sierra 10.12.1.

I published an ebook on Amazon Kindle on Saturday in mobi format. I downloaded (AKA, bought) a copy of my book to check out its looks, and the formatting was exactly how I wanted it. I don’t do wild things in my ebooks, just text.

The I looked in Look Inside, and saw that the formatting there was crazy. Some text was upsized, some was downsized, some was not centered, some was centered when it should have been justified. Some was underlined when it shouldn’t have been. And so on. These, I think, are familiar problems to people here. I know Look Inside is a separate environment from ebooks, and that they just scarf up the first 10 percent of the ebook file to use. And that they are more stringent on HTML usage and so on. But frankly, from a user perspective, that isn’t relevant. Look Inside should exactly match the ebook.

Then I checked my other 2 books I’ve published, which were put up in 2014. The Look Insides for them were also crazy, and I know that wasn’t the case when I published them because I checked them.

I know Amazon just went through an update with Look Inside and that’s had an impact on many books, so maybe that’s a factor, too.

So, here’s my point…

I’ve seen posts here and on Amazon about how to fix these kinds of things, including adding CSS type sections to the mobi file before uploading. But none of these suggestions are really what I’d call a true “fix”. These are patches which may or may not work to resolve the issues.

I’m a good techie and I can do these things. But I have to admit, I object to this. I didn’t pay good money to have issues like this, or to have to do patch management to get around them. There is a problem someplace between Scrivener and Amazon that needs to be fixed. I can’t do that. None of us users can. The Scrivener team has to get with Amazon to get this fixed. There has to be some coordination between Scrivener and Amazon to prevent formatting or other issues in Look Inside. These problems kill sales.

I can’t debug or scaffold around formatting issues like this, nor should I have to. The onus is on Scrivener to run this problem to ground with Amazon and get it resolved. It doesn’t matter if the problem is in Scrivener or KindleGen or someplace else. If the Scrivener team wants to keep its customers, they have to take the lead on getting this problem resolved.

Honestly, as much as I love Scrivener (I have it on Win10, too), if the Scrivener team doesn’t do whatever is needed to get this fixed, whether the fix is in Scrivener, or KindleGen, or some place else, then I’m going back to Word. I’ve used it with CreateSpace and that worked just fine. Overall, though, for my meager writing purposes, I like Scrivener better. But I’ll regress and go back to Word and let Amazon do whatever conversions they want to my uploads. I figure their own tools would at least work with Look Inside.

Please, Scrivener team… get this problem fixed.


You don’t have to upload mobi-files to Amazon’s KDP. You can use most any format you like. So wouldn’t the easiest way be to compile to Word or epub or some other format and upload that file to Amazon and let them do whatever conversions they want?

The easiest solution for L&L would be to remove the mobi formatting option. That would actually solve the problem, although not in the way you prefer. :slight_smile:

Sure, I could do that, but the default file format for Kindle is mobi, and that’s written into all their documentation and the compile dialog, too. I’d really like to hear what the Scrivener team says about this. If using epub or doc/x formats would clear this Look Inside issue up for good, that would be music to my ears.

Yes, the default format for Kindle books sold on Amazon i mobi, but the upload format is actually not. On their Kindle Direct Publishing site it says:

"Kindle Direct Publishing (KDP) helps you publish your book directly to Kindle devices and apps. With KDP, you can convert your book to an eBook and sell it on the Amazon Kindle Store.

Step 1: Prepare
Prepare your manuscript in Microsoft Word or a similar program. KDP supports many formats, but these produce the most consistent results when converted for reading on Kindle devices and apps:
Word (DOC / DOCX)

Uploading an epub or Word file is just as easy and so far I haven’t seen any problems with the Look inside feature at amazon.com for books uploaded that way.

The problem does not seem to appear when the file is uploaded from Word or ePub format, only when the .mobi file is generated by KindleGen. Because KindleGen is an Amazon-supplied tool over which we have no control, the position of L&L is that this is an Amazon issue.

We provide multiple output formats for precisely this reason: to allow each individual user to choose whichever format most effectively meets their needs.


Amazon is being trusted to much in people’s workflows. That’s the problem with one provider tool sets. Inbred thinking when it comes to real debugging and accountability on the part of the provider.

A basic troubleshooting step for these types of issues should always been “alternate file format”. Always.

Thanks for the response.

I can believe that this is an Amazon problem. Do they?

I suspect that Amazon is your most important channel. If they have a problem which affects your customers, you’d want to work with them to get this fixed, wouldn’t you?

I know there are other formats, but your own documentation and even your compile dialog point to mobi as the default format for Kindle. I will try epub to see how that works.

It would be helpful for Scrivener to issue some kind of direction about how to avoid this problem until it gets fixed. If using a different format is the key, then let your customers know that. A proactive email to them would be great. Right now, you have unhappy campers like me out there who keep on tripping over this problem, and don’t see any information coming from Scrivener about what we can do about it.

As you may have discovered for yourself, Amazon is not the most responsive organization on the planet. You would have to ask them whether they are aware of this issue. Nor is it repeatable enough for us to be able to offer any guidance beyond “try another format.”

Scrivener is not and does not claim to be a desktop publishing tool. It is a writing tool with some desktop publishing features. So no, I don’t think it’s necessarily true that Amazon is “the most important channel” for the extremely broad range of projects created by Scrivener customers. See also this Knowledge Base article:
scrivener.tenderapp.com/help/kb/ … th-e-books


I have asked them, and so have many others. It takes a few iterations, but they are actually responding to me. If epub works for my book, then I won’t need to go any further with them.

I know the problem is with KindleGen, and Amazon owns that, not you. But I find it amazing that you’d tell a customer that it’s my responsibility to work with one of your partners to get a compatibility problem with your product fixed.

L&L sells a writing software. The software includes an ability to “export” the text in various formats. Some users choose to send that exported text to a completely different company, which is not a partner to L&L or in any other way affiliated to L&L, and then complain about the way that company treats the text. How on earth could it be the responsibility of L&L to fix that?

It is worth adding that it is the author who in a business partner of Amazon, since they are distributing the book and sharing the proceeds. L&L have no business relationship with Amazon in this context. Their software provides the facility to compile to various formats and, as this thread acknowledges, books compiled using Kindlegen are fine when read on on Kindle readers and tablets.

So the “Look Inside” problems are very specific to Amazon’s conversion software and absolutely not the responsibility of L&L.

I should add that I recently uploaded a book in Epub format and the “Look Inside” seemed unsatisfactory. So I tried again using Kindlegen, with the same result. And books that I uploaded three years ago now suffer from the same issues with “Look Inside,” whereas they used to be OK. So, it is well beyond unreasonable to expect L&L to be able to fix something that very obviously lies within Amazon’s digital walls.

And, of course, Amazon’s conversion software neither knows nor cares how the uploaded files were generated. Again, no control possible by L&L.

In sum, the L&L moderators response is entirely reasonable.


When Scrivener creates a .mobi file, it first generates an .epub file, then sends that file to KindleGen. This can cause the problem to occur.

If a user sends an .epub file to Amazon directly, the problem does not occur.

So the exact same .epub file is handled differently by two different Amazon tools. Please explain how this is a Scrivener compatibility problem.


Well… as a user who is unfamiliar with the internals of your product, I have no knowledge of what happens when I select mobi as the output format other than that a mobi file gets created, and I need to upload it to Amazon to publish my book. All I know is that when I do, it doesn’t work in Look Inside. Your product is my portal to this workflow. I don’t know what happens downstream of that. And as a user, I shouldn’t have to know that. So, my perception, rightly or wrongly, is that if there’s a problem somewhere in this process, your product doesn’t work as it should, and it would therefore be up to you to provide a fix, in whatever form that would be. If there’s a problem with a tool owned by someone else, then it would be in your interest to work with that tool owner to get this fixed because your product depends on that tool working. As a user, it doesn’t matter which part of this process broke. All I know is that I can’t use your product in the preferred manner. And mobi format is the preferred manner for Kindle, according to both the User Guide and compile dialog.

That said, I tried epub, and it seems to have worked. Look Inside is formatted correctly now, although the font seems a little large. That’s good enough for me.

I don’t know why Scrivener offers mobi format as an option. If epub is the “best” format, it would seem that there’s no advantage to offer mobi, too, especially when there’s a problematic product (KindleGen) in the middle of things.

Anyway… I appreciate the discussion. I’m happy that there’s a way to get around this issue, and I can keep using Scrivener as I have been. It really is, for me, a much better writing environment than Word or Pages or other tools. Thanks.

Have you tried to apply that logic to other fields of life? If a dinner gets screwed up it is the responsibility of the manufacturer of the ingredients? Or if we stay within the computer world, your problems with Amazon is really the responsibility of Apple? I mean they created the computer you are using. Or maybe Intel? They created the CPU.

I would actually rephrase your ending remark: As a user, it is your responsibility to know what you are doing and how the tools you are using function.

Kindle books don’t have to be distributed by Amazon. You can sell them via other channels. Many ebook stores sell Kindle format, and you can borrow books in Kindle format from some libraries .

Which we have done, in the form of other output format options.


Of course I’ve applied my logic to other areas of life. No, it doesn’t apply to every other situation where things don’t work out, but only because often it’s just not worth the time and effort to go through it. To use your example, the actions I’d take because my dinner gets screwed up depends on the situation. If I’m making my own dinner, and it turns out that the container of sugar I used happened to be filled at the factory with salt instead, and the food tasted awful, I’d just toss both the food and sugar container out and start over. (Or, more likely, order takeout.) I could go back to the store and get my money back for the sugar being bad, but is that really worth it? If my dinner got screwed up in the exact same way and I happened to be in a restaurant at the time, it wouldn’t be the restaurant’s fault per se, but I’d sure tell the waitstaff to take it back.

About your Apple example… suppose Safari or OSX had a bug that caused file uploads to get corrupted, and that led to my book being unable to be published because the Amazon conversion tools wouldn’t work. My first thought would be that Amazon had a bug in their tools, so I’d report it to them. (Which is what I did with my Look Inside problem.) If I were able to localize the problem to Safari, I’d report it to Apple.

About your Intel example… remember when there was a flaw in the floating point processor of some Pentiums that made them calculate long divides incorrectly? If that happened on my system, I’d report it to the system manufacturer to get fixed, because who can localize a problem like that to the CPU? Let the manufacturer work that. So, why would I try to do problem diagnosis on the publishing process using Scrivener? I don’t have the expertise to do that, so I have to rely on the owner of the product I was using when I saw the problem to do that and determine where the bug was.

I don’t agree about there being other targets for Kindle books than just Amazon. They all resolve to Amazon ultimately. Take Smashwords for example. You can distribute Kindle books through them, but they will just send them to Amazon.

And as a user of Scrivener, my only responsibility is to know what content to put into the tool itself. I went through the Scrivener learning curve to get trained on using the product. And part of that was direction to use mobi as the appropriate file format when compiling for Kindle.

The User Guide says on p. 337 “Kindle eBook .mobi Generate feature-rich eBooks for use in portable reading devices that support the .mobi format, such as the Amazon Kindle. Requires Amazon’s KindleGen, which is only available for Intel based Macs.” That description is incomplete. The Guide also makes a distinction between epub formats and mobi formats by saying in multiple places that mobi is the Kindle format. For epub, it says “Generate feature-rich e-books for use in portable reading devices that support the ePub format, such as the Sony Reader, Nook, Kobo or many iOS based readers (ePub files can be dragged into the iTunes Library to import them into iBooks).” Note that Kindle isn’t included in that, even though you can input epub files to Amazon for Kindle.

What I see here is some finger pointing between Scrivener, who says that KindleGen is at fault, and Amazon, who says that Scrivener generates incorrect HTML. It isn’t up to me as a user to mediate that dispute. But at least I have a viable work around now, and will use epub formats.

Sorry, but that’s not really correct. Where in your documentation do you say that if mobi doesn’t work, use epub instead? You support epub and other formats to have a richer solution set for user requirements, and that’s goodness. But you didn’t supply epub support as a fix for mobi files that fail. It happens to work out that way, but that’s not why you offer other formats for Kindle than just mobi.

Your documentation tells me to use mobi for Kindle. It doesn’t say that I should try out other formats if mobi has problems. So when it doesn’t work, what am I as a user supposed to do? Go beat up Amazon? Well, I did that, and they’re still working on it. But I’d suggest that you update your documentation to say that epub for Amazon works, too, and in fact, can be preferable to mobi, so try that out if something doesn’t work with mobi. That would have saved me, and lots of others, a lot of time and angst.

Dlk, you’re missing the point.

  1. Scrivener does produce mobi output, which can be read on a Kindle device. That is a fact. Not everyone sell what they produce. Some distrubute it for free. And there is market outside the US who doesn’t rely on Amazon.

  2. You are talking about a special feature (Look inside) which Amazon adds on their internet bookstore, and how Amazon’s Kindle Direct Publishing handles diferent file formats when you upload your book, and how that affects the internal Amazon feature ‘Look inside’. That is an issue you should adress at the Amazon KDP User forum.

I was curious, and so did a google search for [kindle “look inside” formatting problems]. I found this blog, which offers one author’s solution for making beautiful ebooks that produce good looking Look Inside output.


I make no claims about the validity of the blog post, nor am I endorsing the product she uses once she’s done editing in Scrivener, but it does seem to be a pervasive problem that most people experience when producing KDP files using Amazon’s own tools, judging by quick glance through the results of my search.

  1. OK

  2. Asked and answered. Please see my previous responses.