One of the most frequently asked questions we get from clients is “Why is my Mobi file so huge? Amazon charges a delivery fee and the Kindle book you made will eat all of my royalty. All of it. All. Of. It.”
The concern, of course, is well-placed. You’re operating a small business and keeping your costs in check is important. There’s a lot that’s out of your control when doing business with Amazon’s KDP, and wrestling it back is a good thing… for your readers and your bottom line.
Mobi file foundations
The best way to answer the “why is the Mobi file so big?” question is to first talk about what goes into an ebook file, in general.
Let’s examine what the components of the ebook are.
The XML (eXtensible Markup Language) files in ebooks—both Mobi files and ePub files—are instructions on how the ebook is structured.
First, there’s an XML file with instructions on how to find another XML file with more instructions. It’s like an invitation to a 90s rave!
The aforementioned second XML file is the OPF (Open Packaging Format) file. The OPF contains the ebook’s identifying information, metadata (author, publisher, category, etc.), the list of individual files that make up the ebook, and the order in which those files should be played.
Finally, there may also be what’s called a NCX (Navigation Center eXtended) file. This sets waypoints in the ebook to help readers navigate through the content. Each chapter is a waypoint, for example. But they can be set anywhere in the content.
These files are the ebook’s content. In most cases, each chapter or content item (title page, copyright page, acknowledgments page, etc.) is given its own XHTML file.
While it may sound counterintuitive to break each piece into its own file, the primary advantage to doing so is efficiency. A single XHTML file with all of the ebook’s content requires the ereader software—whether it’s a Kindle, a tablet or phone—to read the full contents of the file and display only what can appear on the screen.
This process repeats every time a reader turns the page. The longer the book, the longer it takes the device to re-read the contents to the end and decide what to show next.
But there’s another thing at work here: one of the most power-hungry processes for any computer is displaying what it’s doing. Ereader devices are low power machines. Reading long files consumes more power which may likely drain device batteries faster.
CSS files (Cascading Style Sheets) are a set of instructions that define what the content should look like. Basically, CSS is the “formatting” in “ebook formatting.”
There may be other files inside an ebook—like images, the cover, and font files—but the XML, XHTML and CSS files are a given with every ebook.
What goes into a Mobi file?
Here is where things can get complex because of the various types of Mobi files roaming the wild.
There’s the KF7 Mobi file type that’s playable on all things named Kindle. There’s the KF8 Mobi file type that’s also playable on every device and app named Kindle, but has a feature set that works only on select devices and apps (more on that in a moment).
And there’s an update to KF8, called KFX. Our Mobi files are KFX-ready.
We could go in-depth on all of these, but let’s stick to the KF8 Mobi file type. It’s most applicable to the discussion. You with us? We hope so because we’re going to ask you to hang onto your hats for this: there are three versions of your book inside each Mobi file.
Take deep breaths. It sounds worse than it really is. We’ll explain soon.
Mobi file primer: Parts 1, 2 and 3
The first version is one that will play well on legacy Kindle devices and apps, namely Kindle 1, 2 and DX on the devices front, and Kindle Cloud Reader and the retail sample engine at the Amazon Web site. This version is a rather simplified one so that the Kindle legacy systems can still provide a pleasant reading experience to people who use them.
At present, there’s little to no support for the legacy devices. And Amazon has assured us in the past that Kindle Cloud Reader and the retail sampling engine are KF8-ready, but that’s not the case.
The second version is for KF8-ready devices and apps. This version has all the fancy stuff we can do with the features enabled in KF8: block quotes with margins on all sides, embedded fonts, drop caps, better rendering of numbered and bulleted lists, text transformations, and more.
The third version is an ePub file built from the source files (or if an ePub file was used to create the Mobi file, then it uses that as the source).
We’re unsure why this occurs, but our best guess is that helps Amazon learn what authors, publishers and development shops like us are doing with the format so that it can make improvements to the KF8 specification.
The result is a complete Mobi file package that’s roughly three times as large as its ePub file counterpart. Amazon, then, delivers the version that’s supported by the reader’s device or app.
THREE TIMES THE SIZE? You’re killin’ me, Smalls!
Amazon understands this is unfair. After all, it prefers high-quality ebooks that play nicely with the various Kindle ereading systems.
Rather than penalize authors and publishers for making beautiful full-featured ebooks, it calculates the delivery fee based on the smallest version (usually the KF7). Check the Rights & Pricing page at your KDP Bookshelf to verify.
Here’s a screenshot from one of our KDP testing accounts:
If you’re wondering about the size of the Mobi file noted in the screenshot: it’s got 40 high resolution images. 😉
So what does this mean for you?
It means you don’t have to worry about the Mobi file size for the Kindle books we make for you. Our process is designed to produce the smallest possible footprint for the legacy KF7 version.
The text from your manuscript is extracted from the original file as-is using custom-built software. Any basic formatting—headings, lists, bold and italic text—is kept, as well as any literary devices or other fancy effects.
The extraneous code that word processing apps insert is jettisoned, and we split the book into logical parts to ensure the ebooks are device- and reader-friendly.
We optimize images, including your cover, for ereading system display. We ask for large, high resolution assets to ensure the best possible versions go into the finished ebooks. This is important if you’re also getting a POD file from us, as low resolution images don’t print well.
We create the smallest possible CSS file we can. These aren’t heavy files to begin, but efficiency wins the day when it comes to formatting.
We use Kindlegen, Amazon’s command line ebook creation software. Its built-in compression algorithms produce optimized Mobi files ready to upload to KDP.
The result? KDP doesn’t gobble your royalty with the delivery fee. Plus, your readers will thank you for beautiful ebooks, fast page turns, and longer battery life.