Kindle formatting - cursed 2 space indent

Yesterday I spent 2.5 hours trying to figure this out. Maybe someone can help.

I compile for Kindle and everything is great except when I preview my book using Kindle Previewer and also send it to my Kindle Touch, all the paragraph indents are only 2 spaces instead of 5.

I’ve tweaked every setting I could, but nothing works. I’ve searched online for any solutions but haven’t come across any.

If anyone can help, I’d be very grateful.



Anyone ever experience anything like this?


Not every Kindle device handles indentation in the same fashion. Some are very accurate (the newer ones mainly) and others handle it like stops. It will go to the nearest stop you specify but not over until the overage is closer to the next stop. It’s best to sample a variety of device modes in Kindle Preview, and remember that your formatting choices may not be expressed precisely.

Thank you for replying. I realize that different devices may display indents differently. Here are two other bits of info that lead me to believe this is related to Scrivener:

  1. Other books on my Kindle have the correct 5 space paragraph indent
  2. More importantly, when I have created MOBI files from HTML and Calibre, the indents were correctly displayed on my Kindle

Anyone else run into this? Any thoughts/ideas/suggestions would be appreciated.


I can’t compare mobis, but comparing epubs, Calibre uses EMs for measurement and Scriv-Mac uses PX/pixels.

PX would, I believe, depend on the display density of the device and would be different from device to device?

You can adjust the coding of a Mobi file by setting the option in the KindleGen compile pane for saving the source files. You can then edit these freely, and open the OPF file in Kindle Previewer to convert it to a Mobi.

Regarding pixels vs. em units, I don’t see any clear difference between the two in my tests. Both seem to be capable of describing a full range of indents, and in fact they even match up pretty closely with what you see in Scrivener.

So it must be the Kindle version, which one are you using? Do you see different results in Kindle Previewer?


That was great advice - but I still cannot get the indent to work.
I was able to save the source files (which is fantastic!) and I went in and changed the CSS file (stylesheet4.css). I made the p1 text-indent 30 px:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; text-align: justify; text-indent: 30.0px; font-size: 100%}
I then saved the CSS file and opened up the .opf in Kindle Previewer. It compiled a MOBI and displayed the ebook. Ouch! Still indented only 2 spaces.


Cursed, I tell you! Cursed!


Which Kindle Previewer simulation mode are you using, so I can try and compare notes more accurately.

I tried all three. Kindle Paperwhite and normal Kindle give me 2 spaces. Kindle DX gives me 3 spaces.

BTW - thanks so much for helping me with this. I am very grateful.

Well, this isn’t ever going to be a 100% accurate thing. Declaring distances in the stylesheet using fixed sizes like cm or in does not produce reliable results across the Kindle line. For instance if you change the CSS in the source to text-indent: 0.5in, you’ll get a variety of results depending upon the device (to be clear they all shift a bit, but it’s worse with fixed units).

The idea is to use the provided formatting tools to achieve the look you are going for. If you want a roughly five letter width indent in your e-book, then adjust Scrivener’s settings to achieve that look. That might mean exaggerating things a bit in the Formatting compile option pane, but nobody on earth but you is going to see that anyway, so it doesn’t really matter you have 1" indents in your settings if the result is roughly 0.5" on the Kindle?

Does using em instead of px work better at all? I’m just wondering whether I should look at hacking the output to use em instead; whether that offers any advantages.

Thanks and all the best,

The em unit appears to be stable across the board in Kindle Previewer. The problem will be generating the correct value if pixels are what you have to work with, since it is the pixel value that is incorrect (for the Kindle, not a browser). A setting of 0.5" in the formatting pane produces a result of 36 pixels in the CSS, which calculates to 2.250em at a base font size of 12pt @ 100% (16px) which is about half of what it should be. 0.5" is about 2.8em at those settings because the Kindle does not appear to be using the standard browser font size as its base unit. 36px at a base font size of 12.85px is about 2.8em (which as stated, is close to the visual setting which when applied to the .mobi file, produces a result that looks like a web browser). So I guess if you do your calculations with an assumption of a base font size of 12.85px, that might result in correct output.

The formula for this is 1 / x * y, where x is the pixel size of the font and y is the length in pixels you wish to convert to em. So 1 / 12.85 * 36 = 2.801. The result we are actually getting looks visually close to roughly 1.28em (in a web browser) (so an estimated base font size of 28.125px).

The tricky thing about em is that one unit is supposed to be equal to the computed font size (which can be altered by further CSS or the user with their display settings). This is what makes em an appealing web development unit, since it adjusted proportionally to the font size rather than staying fixed. So all of this must mean that the Kindle is using a base font size of around 30px, as opposed to the more standard 16px. Hence the HTML output of a text indent from Scrivener looks fine in a browser, but comes up short with the Kindle’s rendering.


  • You set your indents to 0.5" in Scrivener and compile to .mobi with source on.
  • Open one of the XHTML files in a web browser and note the indent matches Scrivener.
  • Open the .mobi in KP and note the half-width indent.
  • Edit the stylesheet in the source file to 2.8em instead of 36px.
  • Re-open from the OPF and observe that the result now resembles Scrivener and the browser.
  • Thus you’d need to multiply whatever the text engine provides for a pixel width by 0.077821012 (or 1/12.85).
  • So if a user sets the indent marker to 0.5" in Scrivener, you’d hack in 2.80em instead of 36px.

Great info - AmberV - thank you.
I’m wondering if you might post all the settings you used to create the indents in your screenshots. The third line of your text is exactly what I am going for and I want to make sure that my Compile settings are correct.

thanks very much


Randy, in your CSS files, change the text-indent values to “2.80em”, generate a new .mobi with KindlePreviewer, and see how that looks. It looks great on my Paperwhite, as well as in the simulators.

I’m not sure I follow. 36px is half an inch based on the assumptions (not all good these days, but apparently these are the assumptions in the OS X text engine) that 1 pixel = 1 point and 72 points = 1 inch. Other metrics of the text system are based on these same assumptions, so surely the conversion to ems should be based on the base font size in Scrivener’s output, not on the Kindle’s base font?

36 pixels with a base font size of 12 points will calculate to 3em, not 2.250, because it would be the point value and not the pixel value used to determine this (nowhere in Cocoa would a 12-point font return a value of 16 pixels). As I understand it, that would be the correct value. So, unless I’m misunderstanding something, all I would need to do to convert this in code is:

  1. Get the base font size (which I already do anyway for calculating percentage font sizes).

  2. Go through looking for “text-indent” and grab the pixel value.

  3. Divide the pixel value by the base font size to get the em value, and insert that instead.

All the best,

This shows the challenge. Kindle Previewer’s rendering on Retina is fairly awful, but as you can see the em value stays static and is about the right size, whereas the 36px bar at the bottom is far too narrow.

Sorry, you’re right the value is 3.0em, and that would work fine for this. My 2.8em figure above produces a result that appears almost precisely accurate, but that’s probably a transitory match anyway and it would best to just stick with the standard formula.

Here is a handy conversion tool, by the way.

16px = 12pt in a standard browser configuration. I don’t think that has any meaning outside of that context. If you save this to an HTML file and load it in your browser, then adjust the default font size in the browser you can see how it all comes together when set to 16px.


untitled .red {background-color: darkred;width: 1em;height: 1em;} .blue {background-color: darkblue;width: 16px;height: 16px;} .pink {background-color: pink;width: 12pt;height: 12pt;} .green {background-color: darkgreen;width: 3.0em;height: 16px;} .yellow {background-color: yellow;width: 0.5in;height: 16px;} .cocoa {background-color: darkgreen;width: 36px;height: 16px;}

Like I say, it looks to me as though the base size for the Kindle’s “browser” is set higher than 16px. You can make Firefox match the Fire output from the screenshot at about 20px. So technically, 3.0em is not quite identical to what it would be on a computer, but it’s close enough.

Your method worked, Amber. Indent looks great in Previewer. Will now try to send to my Kindle.
Thanks again for al your help on this. You truly solved the mystery.



I’ve changed the code so that ems are used in the next update instead of px, too.