EPUB is a standard with a written rulebook, and most files fail it in the same handful of ways. A manifest that lists a resource the package does not hold. A spine in the wrong order. A nav document with no NCX behind it. We format to the specification, validate against EPUBCheck, and hand you the file plus the evidence that it conforms.
An EPUB is a ZIP archive with rules. Inside it sit your content documents as XHTML, a stylesheet, your images and fonts, a navigation document, and one file that governs everything: the package document, usually named with an OPF extension. Format the EPUB properly and every part of that archive agrees with every other part. Format it badly and the archive still opens, which is precisely the trap.
The package document carries the metadata, the manifest and the spine. The manifest is the inventory: every resource in the book, declared with its media type. The spine is the reading order: which content documents a reader moves through, and in what sequence. If a file exists in the archive but is missing from the manifest, EPUBCheck fails you. If it is in the manifest but absent from the archive, EPUBCheck fails you harder.
EPUB formatting, done to spec, means the content documents are valid XHTML, the CSS is confined to the properties reading systems actually support, the navigation document lists the real structure, the fonts are legally embeddable and correctly declared, and the metadata says who wrote the book, in what language, under what identifier. That is the whole job, and it is entirely checkable.
EPUB 3 replaced XHTML 1.1 with HTML5, replaced the NCX with the navigation document, added media overlays, added proper accessibility metadata and made fixed layout part of the standard rather than a vendor extension. Files written to the older version still exist in enormous numbers, and stores are steadily stopping accepting them.
The practical consequence is that you cannot simply choose one. Modern reading systems want the EPUB 3 nav document. A meaningful number of older Kindles and library platforms still read the NCX. A well-formatted EPUB carries both, which is legal, and which is what we ship.
Metadata, manifest and spine, plus the bindings and fallback declarations. Every rejection we have ever investigated traced back to something written here or missing from it.
An XHTML file with a nav element carrying the table of contents, the landmarks and, for print-mapped titles, the page list. It is content and structure at the same time.
Deprecated in EPUB 3 and still read by hardware in real hands. Including it costs a few kilobytes. Omitting it costs part of your audience their contents list.
Every layer of the archive, from the container up. Nothing left at its default value because nobody looked.
Metadata, manifest and spine authored rather than generated. Every resource declared with the correct media type, every content document placed in the spine in true reading order, and the linear attribute used deliberately so ancillary pages do not interrupt the flow.
An EPUB 3 nav with a table of contents, a landmarks section identifying cover, start of content and back matter, and where the title maps to a print edition, a page list. An NCX ships alongside it for reading systems that still expect one.
Content split into per-chapter documents, each well-formed, each using semantic HTML5 elements and EPUB structural semantics. Well-formedness is not a stylistic preference here, it is a condition of the file being an EPUB at all.
The stylesheet uses only properties reading systems honour, with declared fallbacks where support is partial. Anything speculative is tested on hardware before it is allowed to stay, and dropped if it fails anywhere it matters.
Typefaces checked for an embedding licence, subset to the glyphs the book uses, declared correctly in the manifest and stylesheet, and obfuscated where the foundry requires it. Fallback stacks sit behind every family.
EPUBCheck run against the final package until it reports nothing, plus each retailer's own ingestion validator. The report comes to you with the file, so conformance is something you can see rather than something we assert.
Six recent packages, each one validated, each one shaped by the demands of its content.
Both are legal EPUB 3. They declare themselves differently in the package metadata, they are validated against different expectations, and retailers treat them as separate products.
The package declares no fixed layout, no viewport is set, and the reading system is free to repaginate. Content documents flow, CSS is written in relative units, and the reader controls type size, family and margins.
This is the default target and the one nearly every prose title should meet. It is also the only configuration in which accessibility metadata and screen readers work as the specification intends.
The package carries rendition properties declaring fixed layout, a spread behaviour and an orientation. Every content document sets an explicit viewport in pixels, and elements are positioned absolutely inside it.
Validation is stricter, file sizes are larger, and the reader cannot resize the text. Correct for picture books, comics and heavily designed cookbooks, and wrong for everything else, whatever the designer would prefer.
Six failures, drawn from actual rejection messages. Each one is a class of error, not a one-off accident.
Eight components inside the archive, what we do with each, and what breaks when it is wrong.
| Element | How we build it | Why it matters |
|---|---|---|
| The container file | Written to declare exactly one root file, pointing at the package document at the correct path. | It is the first thing any reading system opens. If it is malformed the book does not exist, and no diagnostic beyond a generic failure is offered. |
| The package metadata | Identifier, title, language, contributors, modification date and accessibility metadata, all present and correctly typed. | A missing language attribute makes hyphenation and text-to-speech behave unpredictably. Missing accessibility metadata now blocks sales to institutional buyers. |
| The manifest | Every file in the archive declared once, with its media type, and with properties such as nav, cover-image and scripted applied where they belong. | Any disagreement between the manifest and the archive is fatal at validation and at ingestion, with no exceptions granted. |
| The spine | Content documents ordered as they are read, with the linear attribute set to no for anything the reader should not fall into unbidden. | The spine is the book's reading order. Getting it wrong does not produce an error, it produces a book that reads in the wrong sequence. |
| The navigation document | XHTML with a nav for the table of contents, a nav for landmarks, and a page list where the title maps to a printed edition. | This drives the device menu on every modern reading system. A malformed nav means a reader has no way to reach chapter twenty except by swiping. |
| The NCX | Generated alongside the nav, listing identical structure, retained for backward compatibility with older hardware. | Deprecated is not the same as absent. Library platforms and older e-readers still look for it, and find nothing if it was omitted. |
| The stylesheet | Restricted to supported properties, written in relative units, with vendor differences handled by fallback rather than by hope. | Reading systems implement CSS partially and inconsistently. A property that works in Apple Books may be ignored on e-ink, and ignoring it is the good outcome. |
| Fonts and font declarations | Licence verified, subsetted, declared in the manifest with the right media type, obfuscated where the foundry requires it. | An unlicensed embedded font is a legal exposure. An undeclared one is a validation failure. A missing fallback is a book set in a typeface you never chose. |
Conformance to the specification is necessary and not sufficient. A valid file can still render badly, because reading systems implement the standard partially and differently.
The official validator is run early, so structural problems surface before styling time is spent on them, and again on the final package. Zero errors is the delivery condition, and the report is handed over with the book.
The most faithful CSS implementation among the major reading systems and therefore the best diagnostic environment. If a rule is going to be honoured anywhere it is honoured here, which makes divergence elsewhere easy to isolate.
Amazon converts your EPUB into its own internal format at ingestion, and that conversion has opinions. Previewer shows what the conversion did. Physical e-ink shows what it feels like afterwards.
Three different engines with three different tolerances. Each is checked for CSS that silently drops, images that scale unexpectedly, and navigation that fails to populate from a nav document it should read.
Reading order, heading hierarchy, alt text, language tags and semantic roles are checked with assistive technology, which is what accessibility conformance actually requires and what buyers increasingly audit.
Thorium and other reference implementations follow the specification closely, so they reveal where a file is relying on a vendor's forgiveness rather than on the standard being met.
The file, its evidence, and everything you would need to hand it to a different specialist tomorrow.
The book itself, conformant, packaged correctly, with the mimetype stored uncompressed as the specification requires and every resource declared. Ready for any store that ingests EPUB, which is all of them.
The validator's output showing zero errors, together with a note on any warning left in place deliberately and why it is harmless. Some retailers ask to see this. Most of your competitors cannot produce it.
The XHTML documents, the CSS, the package document and the nav, unzipped, commented and readable. This is the difference between owning a file and owning a book you can maintain.
Built from the same validated source and confirmed in Previewer, so you approve Amazon's rendering before publication instead of discovering it afterwards.
A short written record of where your file renders differently across systems, what we did about it, and what is simply the nature of the platform. No surprises later.
Your identifier, title, language, contributors and accessibility declarations, written out plainly so you can enter them at each store and have them match what is inside the file.
Five stages, run in the order that catches problems while they are still cheap.
We establish the target: EPUB 3 reflowable or fixed layout, which reading systems must be satisfied, whether a page list is needed, whether accessibility conformance is being claimed formally. These decisions govern everything downstream.
The manuscript is split into per-chapter XHTML, made well formed, and marked up with semantic HTML5 and EPUB structural semantics. Validation runs here, before anything is styled, so structural errors never get buried under CSS.
The package document is written: metadata, manifest, spine, properties, fallbacks. The nav document and the NCX are generated from the actual structure and then checked against it by a person.
The stylesheet is written against known support, then the file is put through the test matrix. Anything that drops on a given system is either given a fallback or removed.
EPUBCheck to zero errors, ingestion checks at each store, then handover with the report, the source tree, the metadata sheet and the reading-system notes.
EPUB work is priced on word count, because length drives the number of content documents, navigation entries and validation passes. The source you send and the structure inside it adjust it from there.
Required steps are marked with *. Optional extras can be removed from the summary with the cross icon.
The kind of content being packaged. This determines how much structural markup the content documents need.
Total word count of the finished text, front and back matter included.
How much conformance evidence and how many derived files you want alongside the EPUB itself.
The amount of structure inside the content documents. Notes, tables and figures all carry markup and validation cost.
How many images sit inside the book. Each one is declared in the manifest, described, and tested for scaling.
Standard is the pace at which the full test matrix can be run. The faster tiers buy priority, not fewer checks.
Two rounds are included. Additional rounds are for books still being corrected while they are being packaged.
This covers the EPUB package and its conformance. Editing, proofreading, cover artwork, ISBN registration, narration recording and uploading to your retailer accounts sit outside it and are quoted separately if you want them.
Two files can look identical in a preview window and behave completely differently the moment a store's ingestion pipeline opens them.
| What you are comparing | Unvalidated EPUB Uploads | Book Formatting Experts |
|---|---|---|
| Package document | ✕ Generated by a tool, never read, with default metadata and a manifest nobody has compared to the archive. | ✓ Authored by hand, every resource declared, every property applied deliberately, the spine in true reading order. |
| Validation | ✕ Run once, if at all, and only after the store has already said no. | ✓ Run early and again on the final package, to zero errors, with the report delivered to you. |
| Navigation | ✕ A nav document alone, so older hardware and library platforms show a book with no contents list. | ✓ Nav plus NCX plus landmarks, and a page list where the title maps to print. |
| CSS | ✕ Written for the previewer on the designer's laptop, using properties half the market ignores. | ✓ Confined to supported properties, with declared fallbacks, then tested across the reading-system matrix. |
| Fonts | ✕ Embedded because they were installed, with no licence checked and no fallback declared. | ✓ Licence audited, subset, declared, obfuscated where required, and backed by a fallback stack. |
| A rejection message | ✕ An error code and a week of guessing which of a hundred things it refers to. | ✓ It does not arrive. If it somehow does, we read the code, name the cause and reissue. |
Every kind of book stresses a different part of the standard.
The simplest conformance target and the easiest to get subtly wrong. One content document per chapter, a spine that matches the reading order, and a nav generated from real headings rather than from bold text pretending to be headings.
Deep heading hierarchies, callouts, sidebars and checklists. The specification has structural semantics for all of these, and using them means an assistive reader can distinguish a warning box from a paragraph instead of hearing them as one continuous voice.
Photographs, letters and quoted documents, which means figures with captions, correct alt text and language attributes wherever the text switches tongue. The language attribute is the one everybody forgets, and text-to-speech suffers immediately for it.
The hardest conformance work in EPUB. Bidirectional footnote links, tables with proper header associations, MathML, figure numbering and a cross-reference apparatus that has to resolve correctly on every system in the matrix.
Verse needs real line semantics, not paragraphs. Runover lines need hanging indents that survive a change of type size, and stanza spacing has to be styled rather than typed as empty lines, which reading systems collapse without telling you.
Rendition properties in the package, an explicit viewport in every content document, spread behaviour declared, and often SVG text. Validation is stricter and the tolerances are tighter, and a small error here stops the file dead.
Most arguments about formatting are matters of taste. This one is not. EPUB is a published specification with a reference validator, and a file either conforms to it or does not. That is a rare and useful thing in creative work: an objective standard you can point at.
Which is why we deliver the evidence and not just the file. The EPUBCheck report either says zero errors or it does not. You should not have to take anybody's word for it, including ours.
Structural errors found after the CSS is written are expensive, because the styling has to be unpicked to reach them. The content documents are made valid first, always.
A property can be perfectly legal and still be ignored on half the devices your readers own. The specification tells you what is allowed. The test matrix tells you what will happen.
The NCX is deprecated in EPUB 3 and it is still read by hardware in people's hands right now. We ship it. The cost is a few kilobytes and the benefit is a working contents list.
Twelve checks against the specification, run on the final package before anything is delivered.
Six situations where the specification, rather than the design, is the problem.
An error code arrived and it meant nothing to you. Send us the message and the file. The code identifies the class of failure, the file shows the cause, and both are usually fixable within a day rather than a fortnight.
You need every title packaged identically, validated, documented, and accompanied by metadata that matches what you have entered at the stores. Consistency at the package level is what keeps a list from becoming a support burden.
You know what an OPF is, you can read a validator report, and you simply do not want to spend three weeks learning the parts of the specification that only matter once. Fair enough. That is what we are for.
A library, an institution or a jurisdiction requires an accessibility conformance claim. That is metadata, semantics, reading order and a formal report, and it is far cheaper to build in than to retrofit.
Library platforms are stricter than consumer stores and older in their tooling. They want the NCX, they want the metadata complete, and they will refuse a file the retail shops would have waved through.
MathML, media overlays, fixed layout with SVG text, scripted content. These sit at the edge of what reading systems support, and they need someone who has already found out where each system stops.
Three, each one testable by you with free software.
The file we hand you passes EPUBCheck with no errors. Run it yourself. The report we include should match the report you generate, exactly, and if it does not we want to hear about it immediately.
If any retailer refuses a package we built, on any conformance ground, we diagnose it and reissue at no charge. Naming the exact rule you tripped is part of the fix, not an extra.
Where a warning is left in place deliberately, it is written down with the reason. We do not deliver a file with unexplained validator output and let you discover it later.
Three habits that keep files conformant and readable at the same time.
A visual effect that is not backed by structural markup is invisible to a validator, a search index and a screen reader. If the reader is meant to understand something, the markup has to say it, not merely show it.
Every risky property, every unusual media type and every deprecated construct gets something behind it. The reading system you did not test on is always the one your best reviewer uses.
A conformant, commented, well-structured EPUB can be updated in an hour when a retailer changes a rule. That is the real return on formatting to the specification, and it arrives years after you paid for it.
Three layers of correctness, each one meaningless without the one below it.
The XHTML parses, the ZIP is packaged correctly, the mimetype is where it belongs. Nothing else can be assessed until this is true, because a file that does not parse is not an EPUB.
The package document agrees with the archive. The manifest, the spine, the metadata and the navigation all describe the same book. This is what EPUBCheck measures, and where most files fail.
The file behaves on real reading systems. Valid and unreadable is a real outcome, and this last layer is the one the specification cannot promise you and the test matrix can.
Rated 4.9 out of 5 across 211 reviewed projects.
I had already paid someone else to format this book once. The chapter headings shifted every time a reader changed the font size and I only found out from a review. This team rebuilt the interior from the structure up and sent me photographs from four real devices before I uploaded anything. First launch day I have not spent refreshing the reviews in a panic.
What sold me was the audit. They came back and told me two chapters had been pasted in from another document and were carrying invisible styles, and that fixing that first would save me money later. Nobody had mentioned it in three years of self-publishing. The proof needed no corrections at all.
My book has footnotes, tables and two appendices, and every quote I got either ignored that or doubled the price because of it. Here the pricing was laid out step by step and I could see what each element cost before I committed. It arrived early and the notes link both ways, which nobody else had even offered.
The proof came back from the printer with the margins exactly where they should be, the running heads correct, and not one chapter opening on a left-hand page. This is my fourth book and the first time I have not had to pay for a second proof copy.
English is my second language and I was nervous about the back and forth. Everything was explained plainly, and when I asked the same question twice they answered as if it were the first time. The revisions were turned round inside two days and I was never made to feel like a nuisance.
I write cookbooks, so the interior is the product. Ingredients have to sit beside the method or the recipe stops working, and the last person I hired reflowed the whole thing into nonsense. These people understood the problem before I had finished describing it and the finished layout is genuinely beautiful.
Straightforward from beginning to end. A fixed price, a delivery window they actually hit, and files that went up to KDP and IngramSpark without a single rejection. I have since sent them two more titles and recommended them to my writing group without hesitation.
My memoir has photographs and I had resigned myself to them looking muddy. They optimised every image, told me honestly which two were too low-resolution to save, and suggested crops instead of shrugging. That candour is worth more to me than the discount I was chasing elsewhere.
I sent them a 480-page reference book with a nightmare of cross-references and a table on nearly every spread. They quoted it accurately, they did not come back later asking for more money, and the index still works. Any author will tell you what that is worth.
The questions authors actually ask us, answered without sales language.
EPUB formatting is the construction of a conformant EPUB package: valid XHTML content documents, a package document holding metadata, manifest and spine, a navigation document, supported CSS and correctly declared resources. EPUB 3 replaced XHTML 1.1 with HTML5, replaced the NCX with the navigation document, added media overlays and proper accessibility metadata, and brought fixed layout into the standard. EPUB 2 files still exist in huge numbers and stores are progressively refusing them, which is why so much of our work is bringing old packages up to the current specification.
The package document, usually an OPF file, is the governing file of the whole archive. It holds the metadata, the manifest and the spine. The metadata says who wrote the book, in what language, and under what unique identifier. The manifest lists every single resource in the package with its media type. The spine sets the reading order. Almost every retailer rejection we have investigated came back to something declared wrongly here, or something in the archive that was never declared at all.
The manifest is the inventory and the spine is the itinerary. The manifest declares every resource the package contains, including images, fonts, the stylesheet and the navigation document, each with its media type. The spine lists only the content documents, in the order a reader moves through them. A file can be in the manifest without being in the spine, which is correct for an image. A file in the spine that is missing from the manifest is a fatal validation error.
Strictly, the navigation document is enough for EPUB 3 conformance and the NCX is deprecated. Practically, you should ship both. Older Kindle hardware and a number of library distribution platforms still look for the NCX, and when they do not find one the reader gets a book with no contents list and no explanation. Including it adds a few kilobytes to the archive. Omitting it silently disadvantages a real slice of your readership, so we generate both from the same structure.
Fatal errors stop the file being a valid EPUB and every ingestion pipeline will refuse it: a manifest that disagrees with the archive, content documents that are not well formed, a missing or malformed container, a remote resource where none is permitted. Warnings are advisory and some are safe to leave, such as certain notices about deprecated but functional constructs. The dishonest move is to ship warnings without reading them. We deliver at zero errors and we explain in writing any warning we have chosen to leave in place.
Because they are different rendering engines with different levels of CSS support, and because Amazon converts your EPUB into its own internal format at ingestion rather than displaying it directly. Apple Books honours your stylesheet closely. Amazon's conversion discards or reinterprets a good deal of it, particularly around fonts, margins and anything involving precise positioning. This is not a fault in your file. It is the market, and the answer is to write CSS that degrades gracefully rather than CSS that only works in one place.
The reliable core is smaller than most designers expect: relative font sizing, line height, margins and padding in em units, text alignment, text indent, basic font family with a fallback stack, page-break-before and after, and simple percentage widths on images. Beyond that, support fragments quickly. Multi-column layouts, advanced selectors, custom properties, floats around images and anything involving precise positioning behave differently on every engine. We use what is supported, declare fallbacks for what is not, and test the result rather than assuming.
You can only embed a font whose licence explicitly permits embedding in an electronic publication. Many desktop licences do not, and a print licence almost never does. Shipping a font without that permission exposes you to a takedown or worse. We audit each typeface, and where the licence allows it we subset the font to the glyphs your book actually uses, declare it in the manifest, and obfuscate it where the foundry requires that. Where it does not allow it, we propose a face that does and looks close.
Media overlays are a part of the EPUB 3 specification that synchronises recorded narration to the text using SMIL, so a supporting reading system highlights each phrase as it is spoken. They are genuinely useful for children's books, language learning and accessibility, and they are supported by a minority of reading systems. If your audience is on Apple Books or on an accessibility platform, they are worth building. If you are chiefly selling prose fiction on Amazon, they will be quietly ignored and the file will simply be larger.
Usually yes, and often within a few hours. Forward the retailer's rejection notice along with the file itself. Retailer error codes are terse but they identify a class of failure, and the file then tells us which specific instance of it you hit. The recurring causes are a manifest that does not match the archive, remote resources referenced from inside the package, content documents that fail to parse, a missing or wrong media type, and legacy markup that the store stopped accepting. All of them are fixable.
It is declared explicitly. A fixed-layout package carries rendition properties in the metadata stating that the layout is pre-paginated, along with the spread behaviour and orientation. Each content document then sets an explicit viewport in pixels, and elements are positioned inside that canvas. A reflowable package declares none of this and leaves the reading system free to repaginate. Retailers treat the two as separate products with separate validation expectations, so getting the declaration wrong is not a cosmetic error.
They decide whether a screen reader can navigate the book and whether an institution is allowed to buy it. Accessibility metadata declares what features the file has: a described reading order, alt text, structural navigation, no known hazards. The semantics decide whether a note is announced as a note and a heading is announced as a heading. Libraries, universities and buyers in several jurisdictions now check this before purchasing, and retrofitting it into a finished package costs several times what building it in would have.
Both, and they must agree. The store displays the cover you upload separately to its catalogue, and the EPUB must also contain a cover image declared in the manifest with the cover-image property. That internal cover is what the reader sees inside their library and on the first screen of the book. Files that omit it show a blank placeholder in the reader's own shelf, which looks like an error to the person who has just paid for the book.
The OPF is the package document, and yes, you can edit it, which is exactly why we ship you the unpacked source. It is an XML file and it is readable. Change the title, add a contributor, correct the language attribute. What you must not do is edit it, rezip the archive carelessly and skip revalidation, because the mimetype file has to be stored first and uncompressed, and a naive zip will break that and produce a file no reading system will open.
MathML is part of the EPUB 3 specification and support across reading systems is uneven. We mark equations up as MathML, so the notation is real, selectable and readable by assistive technology, and we supply a rendered image fallback for the systems that will not display it. The alternative that many people choose, pasting equations in as pictures, produces something that looks acceptable and is unsearchable, unscalable, invisible to a screen reader and unreadable at a large type size.
Yes. Setting text as SVG inside a fixed-layout package preserves the exact letterforms and their exact positions, which matters when the design will not tolerate any substitution or reflow. The cost is that SVG text is not always selectable or searchable, and support for it varies. We use it where the design genuinely demands it, usually in picture books and comics, and we advise against it where ordinary embedded text in a fixed viewport would have done the same job more accessibly.
The package must carry a unique identifier in the metadata. An ISBN is the usual choice and it is what retailers and libraries expect, but the specification only requires uniqueness, so a UUID is valid where you have no ISBN. What matters most is that the identifier inside the file matches the one you enter at the store. A mismatch causes the sort of ingestion problem that is very hard to diagnose from the error message the store sends back.
Because an EPUB is meant to be self-contained. A book that fetches its images or fonts from a URL will render on the machine that built it, where the network is available, and then fail for a reader on a plane, on an e-ink device with the radio off, or after the hosting server is retired. The specification permits remote resources only in narrow circumstances. In practice we package everything the book needs inside the archive, which is the only way the file is durable.
Validation first with EPUBCheck, run early against the content documents and again on the final package. Accessibility tooling next, to check reading order, headings, alt text and language. Then the reading-system matrix: Apple Books, Kindle Previewer and physical e-ink, Kobo, Nook, Google Play, Adobe Digital Editions and a reference reader that follows the standard closely. The last of those is the important one, because it shows where a file has been relying on one vendor's forgiveness rather than on actually meeting the specification.
Yes, and it is built from the validated EPUB rather than converted sideways from anything else. Amazon accepts EPUB directly at upload and performs its own conversion at ingestion, so the derived file we produce and check in Previewer is really a preview of what that conversion will do to your book. Seeing it before you publish means you can adjust the stylesheet where Amazon has reinterpreted something, instead of finding out from the first reader who mentions it in a review.
Whether you have a manuscript to package or a rejection message you cannot decode, we will look at it, name what is wrong at the level of the specification, and quote a fixed price to make it conform.