How To Create A Valid EPUB File Without Any Technical Knowledge

Somewhere between finishing a manuscript and seeing it live on a retailer's shelf sits a moment a lot of first-time self-published authors don't expect: the rejection email. You uploaded a file that opened fine on your own laptop, looked right in the preview, and read perfectly on your phone — and the platform bounced it anyway, with an error message written for someone who already knows what a manifest is. Nothing about that experience means you did something careless. It means EPUB, the format almost every ebook retailer expects, is a real file specification with real structural rules, and "it opens and looks fine" is not the same thing as "it's valid." This piece walks through what validity actually means, why the gap between the two trips up careful, non-technical writers constantly, and the concrete paths to closing it — including the free ones — without requiring you to learn to code.

This matters whether you drafted the manuscript entirely by hand in a word processor or generated most of it with an AI ebook generator and edited it into shape afterward — the file-format problem sits downstream of how the words got written, and it treats both origins exactly the same way. A manuscript is not an EPUB yet, no matter how it was produced, until it's passed through a process that turns prose into that specific internal skeleton correctly.

What "valid" actually means for an EPUB file

An EPUB isn't really one file. It's a zip archive wearing a single-file costume, and inside that archive sits a small, specific skeleton: the actual chapter text as individual XHTML files, a package file (usually called the OPF file) that lists everything in the book and declares its metadata, a manifest inside that package file naming every resource the book uses, a spine that puts the content files in reading order, and a navigation document that builds the table of contents a reader's device displays. "Valid" means each of those pieces is internally consistent and correctly formed according to the EPUB specification maintained by the W3C — the same standards body that maintains the core specs the open web runs on. The W3C's EPUB 3.3 specification is the actual document that defines what a package file, a manifest, a spine, and a navigation document are supposed to contain; you'll never need to read it cover to cover, but it's worth knowing it exists as the ground truth, because every retailer's validator is ultimately checking your file against rules that trace back to it.

Here's the part that catches non-technical writers off guard: a reading app doesn't have to enforce any of this strictly to open your book. Most ereader software is written to be forgiving — it'll do its best with a malformed file rather than refuse to display anything, because a blank screen is a worse user experience than a slightly broken layout. That leniency is exactly what creates the trap. You can build a file with a missing manifest entry, a navigation link pointing at a chapter file that no longer exists, or an internal reference that's technically malformed, open it in three different apps on your own devices, watch it work fine in all three, and conclude the file is done. Then a retailer's ingestion pipeline — which is not built to be forgiving, because it's making a business decision about what gets sold under its name — runs an actual conformance check and rejects it outright.

Why KDP, Apple Books, and Kobo reject broken files

Every major retailer validates a book's file before it goes live, and none of them are checking whether the book merely displays — they're checking whether the file conforms to spec closely enough that it will display correctly and consistently on every device and reading app a customer might use, not just the one you happened to test on. Apple's own publisher guidance is explicit about this: EPUB files submitted through Apple Books go through automated validation before import, and the documentation spells out specifics most authors never think to check — every file inside the archive has to be listed in the manifest, filenames and internal links need properly encoded characters, and a real navigation document with a working table of contents is a hard requirement, not a nice-to-have. Apple's own publisher asset guide lays out that a book "containing unmanifested files will fail import" — meaning if your zip has even one stray file that isn't declared anywhere in the package structure, the whole submission gets rejected, not just flagged.

Amazon's KDP takes a related but slightly different approach: it accepts EPUB but explicitly recommends validating the file and points authors toward its own Kindle Publishing Guidelines for the fuller technical specification, because Kindle devices apply an additional layer of processing on top of baseline EPUB conformance. Kobo, similarly, runs incoming files through its own ingestion checks before they appear in its store. The common thread across all three isn't that they're each inventing their own private rulebook — it's that they're all enforcing, at minimum, the same baseline structural conformance the format itself requires, then layering their own platform-specific handling on top of it. A file that fails at the baseline level fails everywhere. A file that passes the baseline level still has to clear each retailer's own layer, but at least it's not getting rejected for the same reason twice.

The frustrating part, from a non-technical writer's chair, is that the rejection message rarely explains any of this in plain terms. You get a code, a file path, and a line number, and none of it maps to anything you consciously did while writing the book — because you didn't do it while writing the book. You did it while formatting it, usually without realizing formatting and validity were even connected.

It's also worth separating two different kinds of failure a writer can run into, because they get treated very differently downstream. A book can be structurally valid and still get rejected for a content or metadata reason — a cover image at the wrong resolution, a mismatched title between the file and the listing, a category that doesn't fit the retailer's taxonomy. Those are real submission problems, but they're not what this piece is about, and they're generally easy to diagnose because the rejection message for them tends to be written in plain, specific language. Structural invalidity is the harder failure mode precisely because it's invisible until a validator goes looking for it, and the fix isn't a form field — it's the underlying file itself.

The specific things that actually break a file

A handful of mistakes account for the overwhelming majority of EPUB validation failures among writers with no technical background, and every one of them is a formatting habit that feels harmless in the moment.

Heading hierarchy that doesn't match what it looks like. Word processors let you make text look like a heading — bigger, bold, centered — without actually marking it as a heading in the document's underlying structure. When that file gets converted to EPUB, a chapter title that was only ever styled to look big doesn't register as a real heading at all, while a pull-quote you made large and bold for emphasis might get misread as one. EPUB's navigation and accessibility features depend on the actual semantic structure — H1 for a chapter title, H2 for a section within it, and so on, in a sequence that doesn't skip levels arbitrarily — not on how something looks on screen. A manuscript that jumps from an H1 straight to an H4 because that's the font size that looked right isn't just a cosmetic issue; it can break the automatically generated navigation entirely.

A table of contents that points at nothing. Every EPUB needs a navigation document — the file that builds the clickable table of contents a reading app displays — and that document works by linking to specific locations inside your content files. If you rename a chapter file, split one chapter into two, or reorder sections after the navigation document was already built, and nothing updates the corresponding links, you end up with a table of contents entry that points at a chapter that no longer exists at that address. To a human eye everything still looks fine, because you're reading the actual chapter text, not clicking every single navigation link to confirm it lands correctly. To a validator, a broken internal link is a hard failure.

Embedded fonts done incorrectly. Wanting your ebook's typography to look intentional rather than whatever default font a reading app falls back to is a completely reasonable instinct, but embedding a font file inside an EPUB has two separate failure modes non-technical writers hit constantly: using a font you don't actually have redistribution rights for (most desktop font licenses don't automatically extend to embedding and distributing the font file inside a product you're selling), and embedding a font without the specific obfuscation handling some retailers require for licensed fonts, which is a technical step most word processors and casual conversion tools simply don't perform. When in doubt, the safer default is to let the reading app apply the reader's own chosen font rather than fighting to lock in a specific typeface — most retailers' validators are considerably less forgiving about fonts than about almost anything else in the file.

Files that exist but aren't declared, or are declared but don't exist. This is the manifest-mismatch problem Apple's guidance calls out directly, and it usually comes from an export tool that leaves temporary or leftover files inside the zip archive, or from someone manually editing the package file and typing a filename slightly wrong. Either way, the fix a non-technical writer needs isn't to hand-edit XML — it's to use a tool that builds the manifest and the archive together, from the same source of truth, so the two can never drift apart in the first place.

Stray characters and encoding problems. Curly quotes, em dashes, and special characters that came from pasting text out of a word processor sometimes carry over as the wrong character encoding, especially when a manuscript has passed through several different editing tools before export. EPUB expects consistent UTF-8 text encoding throughout; a handful of misencoded characters usually won't crash a validator the way a missing manifest entry will, but they're exactly the kind of small, invisible-until-it-isn't defect that erodes reader trust once the book is live.

None of this is really about being technical. It's about the fact that a manuscript and a valid EPUB are two different objects, and the process that turns one into the other has a lot of small, specific places to go wrong — places a writer focused on the actual book has no particular reason to know about in advance.

Path one: let the export step catch it before you ever see it

The most reliable way to sidestep everything above isn't to learn XML — it's to use an export path built specifically to produce a structurally sound file and to refuse to hand you a broken one. This is the role a purpose-built AI ebook creator can play that a general-purpose word processor or a from-scratch manual build can't: because it controls the entire pipeline from manuscript to package file, it can generate the manifest, spine, and navigation document from the same underlying source of truth as the actual chapter content, which removes the entire category of mismatch errors that come from a human manually keeping two representations of the same book in sync.

On eBookable specifically, the EPUB export path assembles the full manuscript from every chapter in order, builds the package structure around it, and — per the platform's own architecture — runs a structural validation step before the file is ever returned to you, rather than handing back whatever it produced and letting you discover problems at a retailer's ingestion step instead. If that validation step finds a structural problem, the export fails with a clear signal instead of silently shipping a file that looks done but isn't. That's a meaningfully different guarantee than "the file downloaded successfully" — it's the difference between a tool that produces a file and a tool that produces a file it has already checked. EPUB export is available on eBookable's Elite and Ultra plans; it isn't part of the Free preview or the Pro tier, since it sits alongside the rest of the platform's publishing-prep tooling rather than the core drafting features.

It's worth being precise about what that validation step promises and what it doesn't. It checks the structural integrity of the file the platform builds — the pieces covered earlier in this piece. It doesn't, and can't, guarantee that every retailer's additional platform-specific review will wave a book through unconditionally, since store-side checks sometimes layer on content or metadata requirements that have nothing to do with file structure. What it removes is the category of failure this piece has been walking through: a broken package file, a mis-declared manifest, a dead navigation link — the mechanical mistakes a non-technical writer has no real way to catch on their own before a retailer catches it for them.

Path two: doing it yourself with free tools

If you'd rather build or convert the file yourself, that's entirely workable too — it just means taking on the validation step manually instead of having a tool run it for you. Calibre, the widely used free ebook management application, can convert a manuscript into EPUB format and gives you reasonably direct control over the package structure, the table of contents, and metadata. It's a genuinely capable tool for a self-publishing author on a budget, and it's free.

What Calibre doesn't do on its own is run the kind of rigorous conformance check a retailer applies. For that, the tool to know about is EPUBCheck — the open-source validator maintained under the W3C and the DAISY Consortium, and, not coincidentally, functionally the same engine much of the retail ecosystem's own validation is built on or checked against. The EPUBCheck project page describes it plainly as "the conformance checker for EPUB publications" — it's a free, downloadable command-line tool (some retailer-facing tools and a few third-party desktop apps wrap it in a graphical interface if the command line feels like a bridge too far) that reads your file and tells you, in a structured report, exactly where it fails to conform to spec. Running it isn't glamorous, but it's genuinely within reach without a programming background: download the tool, point it at your EPUB file, and read the output.

That output is where most non-technical writers get stuck, not because the tool is hard to run, but because the report reads like it was written for someone who already knows what every term means. It generally separates findings into errors — things that will actually break the file for a reader or get it rejected outright — and warnings, which flag something worth a second look but won't necessarily sink a submission. A line reporting a broken reference in the navigation document is telling you, in blunter language, exactly the dead-link problem described earlier: a table of contents entry pointing at a chapter file that doesn't match anything actually in the archive. A line about an unmanifested file is the same missing-declaration problem Apple's guidance flags directly. Once you know the handful of failure categories this piece has already walked through in plain language, an EPUBCheck report stops reading like a wall of jargon and starts reading like a list of specific, fixable problems, each traceable back to one of the same handful of causes.

The tradeoff of the free-tools path is honest and worth naming: it's genuinely free, and it gives you full manual control, but it also puts the entire responsibility for catching a problem on you, after the fact, rather than building the check into the process that created the file. For a single short ebook, that's a completely reasonable trade. For a longer manuscript with a lot of chapters, embedded images, and a hand-built table of contents, the number of places a small mismatch can creep in scales right along with the book's length.

A short checklist before you upload anywhere

Whichever path you take, a few checks are worth running through before a file goes to KDP, Apple Books, or Kobo:

• Open the exported file in at least one dedicated EPUB reader (not just a browser extension) and click through every table of contents entry, not just the first few.
• Confirm chapter headings are actually formatted as headings in your source document, not just visually large text — this is the single most common invisible cause of navigation problems.
• If you embedded a custom font, double-check you have redistribution rights for it, or skip embedding it and let the reading app supply its own.
• Run the file through EPUBCheck at least once if you built it manually, and read every error line, not just the count at the bottom.
• Don't assume "it opened fine on my phone" is the same test a retailer's ingestion pipeline is running — it isn't.

The takeaway

A valid EPUB isn't a bonus feature of a finished ebook — it's the actual definition of finished, from a retailer's point of view. The gap between a file that looks right and a file that's structurally sound is invisible to a reader scrolling through it on their own device and completely visible to the automated check standing between your upload and a live listing. Whether you close that gap by using an export path that validates before it hands you anything, like eBookable's EPUB export, or by building the file yourself and running it through EPUBCheck before you submit, the goal is the same: catching the manifest mismatch, the dead navigation link, or the malformed heading before a retailer's rejection email does it for you. None of it requires learning to write XML by hand. It requires knowing what "valid" actually checks for, and choosing a process — whether that's a purpose-built AI book writer with validation built into its export step or a careful manual pass with a free checker — that catches the problem before a customer ever sees the book.