Switching from ePub2 to ePub3

I am currently converting all my eBooks from ePub2 to ePub3 and have encountered an issue. Although I choose the compiler option to remove the first line indent after headings and spaces, the choice does not seem to work in the compiled format. What am I doing wrong? Any advice?

There isn’t enough information provided to say for sure. The first thing I’d be suspicious of is the use of styles for body text though, which attempt to preserve the established look even over other settings.

If that’s not the case, could you right click on your compile format in the left sidebar, export it to a file and attach a copy here? I can apply that to a sample project and see what is going on more clearly.

1 Like

Hi Amber,

Thank you much for your kind help.
No, I’m not using styles and do set necessary formats on the compiler only.
Here’s the Compile format I was using.
Thomas Format Standard.zip (5.4 KB)

Hope this helps,

Okay, I think I see the problem (with the “Kapitel” section layout). There is a section heading here, but it is just being printed as normal paragraph text rather than a proper heading. So what is happening is that the indent rule is being applied to the heading instead of what you would consider to be the first paragraph—because to the setup it’s actually the second paragraph.

To fix it:

  1. Open the compile format designer to Section Layouts, and click into the heading text. Use the Format â–¸ Copy Formatting command.
  2. Switch to the Styles pane and click on “Heading 1”. Use the Format ▸ Paste Formatting command in the sample text.
  3. In the Format Bar, on the left side, change the setting from “Body Text” to “Heading 1”.
  4. Go back to your Section Layout, put the cursor in the heading line, and use the Format Bar to apply the “Heading 1” style.

That should fix it! You could also not use styles, and instead just put the cursor into the Section Layout’s heading text, and use the Format ▸ Paragraph ▸ HTML Header Level ▸ H1 menu command. Either way accomplishes the same goal, of having a proper heading in your ebook instead of just a bunch of formatted paragraphs—but I prefer styles whenever I can use them as it keeps things neater. If you want to use this same heading for another type, they can both pull from the same formatting rather than having to maintain them separately.

One other thing I would consider doing is changing the Section Layout setting, at the bottom, from “Text and notes use custom formatting” to “Text and notes use default paragraph formatting”. You would then establish the global body text look in the top half of the CSS pane. Any layouts using body text (like “Vorchau” potentially) would also have this change made to them.

The idea here is similar to styles—have one central thing that drives formatting instead of a bunch of separate settings. This will also make a cleaner ebook, with simple paragraphs instead of applying custom formatting to them all.

It’s worth keeping these in mind for any other compile formats you upgrade from ePub2. The default settings for taking an older format and using it with ePub3 is less optimal, but biased toward trying to make things work the way they used to with less setup. That may not always work in your favour though, as witnessed here, and ultimately it will be better to have a cleaner and more modern setup going forward.

Custom paragraph formatting does certainly have its uses. For example the “SciFi-World Logo” is an excellent example of where you don’t want to use default body text formatting.


Hi Amber,

Wow, thank you so much for your detailed answer. I’ll get to work right away and implement your tips. I think I now understand better what happened and thank you very much for your kind help. I will get back to you as soon as I have corrected the compile format accordingly.
Kind regards,

1 Like

Your tip solved the problem. Both formats, ePub3 and KF8, now look exactly as I wanted. You have helped me a lot. Thank you very much again! Now I can go to the finishing touches and have learned a lot today.
Best regards from Stuttgart,

Glad to hear the transition has been smooth, this one thing aside!

1 Like

Good day. I have got one last quick question with regards to the KF8/Mobi format Scrivener is compiling. The file extension I got from the compiler is “.mobi" (Comes from the former MobiPocket I guess). Kindle KF8 files I found on the web seem to end with ".kf8” (Kindle Format 8).
Question: Is it basically the same format, just a different extension or is there a difference between both?
I’m asking, because for uploading content to KDP I saw *.kf8 in the list, also *ePub2 & *ePub3 but no *.mobi Format anymore.

For reflowable ebooks, the mobi format has been deprecated.

KDP now only accepts the mobi format for fixed-layout books. Otherwise the company wants docx, kpf, or epub for ebooks.

Think you can safely ignore mobi, unless you are producing a fixed-layout book. I imagine the mobi compile format will not be included in the next version of Scrivener.



The main reason we chose to keep it around is to facilitate long-form proofing on Kindles, without having to resort to manual conversion workflows involving third-party software. When they deprecated Mobi, they got in touch with us to let us know, and we asked at that time what they recommend authors use to proofread, since ePub is a no-go on their devices and mobile apps. Their answer was that everyone should use Kindle Previewer.

That is of course ridiculous. It’s perfectly fine for publishers and designers as a design tool, but few are going to want to sit up at desk and read out of a program that has zero features for reading and annotation—even to the point of not remembering where you left off.

So Mobi is around for those that prefer to read copies on devices, and for that reason we’ll probably keep it around for a good while. There are potentially some options for keeping this route around beyond the eventual demise of .mobi as well, but we’ve yet to explore them.

1 Like

Thanks for sharing the insight.

Users can go from ePub → Kindle Previewer → mobi if they want to proof on Kindles. Not a huge additional effort in the Herculean process of writing and editing.

I assumed it would be easier for it to be dropped from Scrivener: one less archaic coding stream to have to deal with, and one less facet for support to have to answer questions about. Declutters Scrivener for everyone in the developer-to-user chain and passes on any user issues to Amazon.

That’s the editor in me hacking away at the detritus.

Thankfully I don’t have to compile for direct publication and I have never used a Kindle.

You have my gratitude and admiration.


As always, there are several views on this. For example, I am a full-time self-publisher and use Kindle as one of my main publishing channels. One reason I value Scrivener is not only for writing, plotting and organising my manuscripts, but also for eBook production. All in one app, that’s what makes Scrivener stand out for me. So far, I’ve always been able to use the compiler to output my novels directly and publish them on KDP, and I’m sure that’s how a large proportion of users who self-publish do it. Restricting these functions would be fatal and would disrupt my workflow and that of other authors.
So every user has his or her preferences. Personally, I would remove the whole styles complex from the app and turn the editor into a pure markup editor, simplify and rework the compiler a little, but in no way restrict the export functions.

1 Like

Indeed. My points were simply that Scrivener can create files ready for publication through KDP without mobi being involved, and that users can move a Scrivener-generated file to a Kindle using tools provided elsewhere. Mobi is dead. Don’t think Scrivener needs to support it. Just an opinion about getting rid of bloat.

Share your thoughts for the editor and compiler (which is the way other apps work).



1 Like