How can I optimize an epub file, in order, but not limited to:

  • limit the chances of compatibility issues?
  • make it faster to load and to be processed from the reader?
  • keep its look consistent throughout different devices and readers?
  • 1
    This question is meant to be answered with many different tips & tricks. Feel free to edit my answer to improve it or add you own if you have other ideas.
    – Sekhemty
    Commented Dec 30, 2013 at 22:26
  • 1
    Stack Exchange works with questions that have one answer not asking for a list of tips as you have done here. Please edit the question to make it more direct
    – mmmmmm
    Commented Dec 31, 2013 at 10:02
  • but not all questions can be answered with a single solution, what about things that can be addressed with multiple different tecniques?
    – Sekhemty
    Commented Dec 31, 2013 at 10:17
  • 1
    Also see meta.ebooks.stackexchange.com/questions/112/…
    – mmmmmm
    Commented Jan 1, 2014 at 14:58
  • 2
    I think there are 3 good quesitons here.. and probably 20 others in the same vane. Breaking this question up would be good.
    – Chad
    Commented Jan 15, 2014 at 21:41

3 Answers 3


Limiting compatibility issues

  • Perform a validation of the file structure. See this question about this subject.

Making it faster to load

  • Keep the size of individual internal HTML files small. The reader usually load them individually when needed, and it is (obviously) faster to load a small file than a big one; as a rule of thumb the size limit is considered to be 250~300 KB. It is better to have many smaller files than a single heavy one, so try to have any file cover a single chapter or section rather than the whole book.
  • Always to keep the individual files smaller and to reduce required processing power, use a distinct stylesheet to define the CSS styles, rather than putting them inside each individual HTML text file.
  • Try to keep the HTML code of you files as simple and tidy as possible. I.E. use <i> and <b> tags for italic and bold text instead of their relative <span style="font-style:italic"> and <span style="font-weight:bold">.
  • If you are including images, keep their size as small as possible. Consider the screen resolutions of the devices where the book will be read, whether they have color or B/W displays, and if the images are photographies or other complex illustrations, or instead simple drawings or diagrams.

Keeping it consistent

  • Keep the visual look as simple as possible; if you want to include some fancy layout (i.e. for chapter titles or other particular portions of text like quotes and so on) try to define it as properly and accurately as possible with CSS styles, and test the outcome with the greater number of reading devices and software that you can.

  • If you want to use any specific font, be sure to include it in the epub file and to define its @font-face and styles in the CSS file.


The EPUB 3 specification1 suggests including embedded fonts for compatibility:

3.4 Fonts

EPUB 3 does not require that Reading Systems come with any particular set of built-in system fonts. As occurs in Web contexts, Users in a particular locale might have installed fonts that omit characters required for other locales, and Reading Systems might utilize intrinsic fonts or font engines that do not utilize operating system installed fonts. As a result, the text content of an EPUB Publication might not natively render as intended on all Reading Systems.

To address this problem, EPUB 3 supports the embedding of fonts to facilitate the rendering of text content, and this practice is recommended in order to ensure content is rendered as intended.

Support for embedded fonts also ensures that characters and glyphs unique to an EPUB Publication can be embedded for proper display.

1Epub 3 Overview - Draft Specification 8 November 2013


You cannot optimize and make it faster to load and to be processed from the reader in a generic way for all possible readers and probably not for all available readers¹.

The reason is that there are conflicting elements involved that lead to different loading results on different device hardware configurations. For the reading device these configurations include:

  • CPU speed
  • availability of CPU cache(s) and its size
  • work memory speed (access time, width of access path)
  • storage memory speed if EPUB stored internal
  • SD card interface speed and SD card read speed if the EPUB is stored externally

From the above the SD card speed is most obviously variable, as SD cards are sold in different classes.

Assuming there is no DMA involved all of the EPUB data has to go through the CPU. Uncompressing data from an EPUB (ie. ZIP

If the storage is slow and CPU speed high, you better compress the data in an EPUB (use zip DEFLATE). If storage is fast and CPU speed low than you better not compress the data in an EPUB (use zip STORE). Decompressing compressed data from an EPUB file is non-trivial, including bit manipulations and tables. Implementing a decoding library for DEFLATE—although to a lesser extend then encoding—involves trade-offs between speed and memory requirements.

So just deciding² whether you should compress the data in an EPUB file or not—in order to make them faster to load is a hard to answer in general, although you should be able to do so for a specific reader after some testing.

¹ In this example I only approach the compression vs non-compression issue to make a point. Other elements that at first glance don't seem to have a global optimal solution: 1) Size of images so they don't require rescaling on any device and have maximum detail. 2) Use the deflate algorithm on JPEG images to get a little bit of extra compression for a double decompression to pixel information. 3) EPUB2 vs. EPUB3 issues. E.g. EPUB3 forces use of CSS for things like font size (as <font> is not supported in HTML5). However an EPUB2 device might render <font> faster than something specified in a separate CSS file, especially if applied only once in the HTML file.

² The resulting difference of any particular trade-off might be minuscule compared to other things that influence loading speed. That is of course irrelevant: every tiny bit helps, some just more than others.

  • Are there really SDCards fast enough that decompressing an average ebook would take longer than ANY SDCard IO operation on even the lowest end modern CPUs?
    – DVK
    Commented Jan 1, 2014 at 19:55
  • @DKV I don't know how the different parts interact and what is the limiting factor. The SDCard IO is probably slow, but even then, for low compression ratio's (as with JPEG image in an EPUB) there will be a point where you have to decide not to compress. For HTML files that is probably more clean cut in favour of compressing.
    – Anthon
    Commented Jan 1, 2014 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.