What RSC-005, RSC-012, PKG-007 and the other common EPUBCheck codes actually mean, the fix for each, and which stores reject which errors
An EPUB "fails validation" when EPUBCheck — the standard validator, maintained by the DAISY Consortium for the W3C — finds something in the file that breaks the EPUB specification. The triage is always the same three steps: run EPUBCheck, read the part of the message after the error code (the code is a category; the text after it names the actual problem, with a file, line, and column), then fix that file at that line. Most failures come down to a handful of causes: broken internal links (RSC-012), markup that violates the schema (RSC-005), files that are referenced but missing — or present but undeclared (RSC-007, RSC-001), and an archive that was re-zipped wrong so the mimetype file is no longer first and uncompressed (PKG-006, PKG-007).
We build EbookFormatter's EPUB generator ourselves — it assembles the ZIP container byte-by-byte, computes the checksums, writes the manifest — so we spend a lot of time on the other side of these errors: making files that never trigger them. This guide translates each common code into plain English, gives you the concrete fix, and then does something the error-code lists skip: shows you, from the stores' documentation and well-attested field reports, which retailers actually reject which errors — because "my EPUB failed validation" means something different at Apple than it does at Amazon.
EPUBCheck is a command-line Java tool. The current release (as of July 2026) is v5.3.0, downloadable from the official GitHub releases page, and it runs like this:
java -jar epubcheck.jar your-book.epubTwo things people expect to exist, don't. There is no official web-based validator — the old IDPF validator at validator.idpf.org is dead, and neither the W3C nor DAISY hosts a replacement. And Kindle Previewer is not a validator — Amazon's own documentation describes it as a visual preview tool for checking how your book looks across devices, not a spec checker. If you don't want to install Java, the practical options are Draft2Digital's free web validator (it runs EPUBCheck on an uploaded file, no account needed) or the pagina EPUB-Checker, a desktop app that wraps EPUBCheck in a GUI.
When it runs, EPUBCheck reports findings at five severities: fatal, error, warning, info, and usage. The ones that make a file "invalid" — and the ones stores care about — are fatals and errors. Every code covered below is an error in EPUBCheck's default configuration; we verified each against the EPUBCheck source. Warnings are advice: worth reading, rarely blocking, though some strict channels (more below) won't take files with warnings either.
To fix anything, you'll sometimes need to see inside the file: an EPUB is a ZIP archive, so copy it, rename .epub to .zip, and unzip — or open it directly in Sigil, which is safer (more on why below). The prefix of each error tells you which layer of the file is broken: RSC codes are resource problems (links, references, markup inside content files), OPF codes live in the package document — the manifest that declares what's in the book, PKG codes are container problems (the ZIP itself), and NCX codes concern the legacy table-of-contents file. Here's the map, then the details:
| Code | Plain-English meaning | Usual culprit |
|---|---|---|
RSC-005 | A file breaks the format's markup rules | Word/Docs exports, hand-edited files, duplicate ids |
RSC-012 | A link points to an anchor that doesn't exist | TOC entries after headings were renamed or deleted |
RSC-007 | Content references a file that isn't in the EPUB | Renamed/deleted images, wrong paths, case mismatches |
RSC-001 | The manifest declares a file that isn't there | Stale manifest entries after deleting files |
RSC-011 | A link targets a document that isn't in the reading order | TOC or landmark pointing at a non-spine file |
OPF-014 | A file uses a feature it didn't declare | SVG, scripting, or remote resources without a properties flag |
OPF-030 | The book's unique identifier is missing | Renamed or deleted dc:identifier |
PKG-006 / 007 | The ZIP container was assembled wrong | Unzipping and re-zipping with a general-purpose tool |
NCX-001 | Two copies of the book ID disagree | Tools regenerating one ID but not the other |
The most common and the most misunderstood, because it's generic: RSC-005 means one of the files inside the EPUB failed schema validation — the automated check of the format's markup rules, done against RelaxNG and Schematron schemas. The message is literally Error while parsing file: %1$s, and that placeholder is filled with a sub-message naming the real problem: a duplicate id attribute, an element that "is not allowed here," a missing required attribute. Googling "RSC-005 fix" is a dead end — the fix lives in the sub-message, not the code.
Typical sources: manuscripts exported from Word or Google Docs (both emit messy HTML that violates EPUB's stricter XHTML rules), and hand-edits in Sigil or Calibre that left a tag unclosed or an attribute misspelled. The fix: open the named file at the reported line and column, read what the sub-message says is wrong, and correct exactly that. If the same sub-message repeats dozens of times — duplicate ids are notorious for this — fix the pattern at the source (usually the tool that generated the markup) rather than whack-a-moling each instance.
A link inside the book — <a href="chapter3.xhtml#scene2"> — points at an anchor, and no element with id="scene2" exists in that file. This is the classic broken-TOC error: you renamed or deleted a heading, and the table of contents still points at the old anchor. Footnote back-links are the other frequent offender.
The fix is mechanical: for each reported link, either create the missing id at the target or repoint/remove the link. Note that fragment matching is case-sensitive — #Scene2 does not find id="scene2". This error matters more than it looks: it's the canonical example of an error one store shrugs at and another rejects outright (see the retailer matrix below).
These are mirror images. RSC-007 (referenced resource could not be found in the EPUB) fires when your content points at a file that isn't in the archive: an <img src="images/map.png"> whose PNG was renamed, a CSS url() to a deleted font, a wrong relative path. RSC-001 (file could not be found) fires when the manifest — the package file's declared inventory — lists a file that isn't actually in the ZIP, usually a stale entry left behind after you deleted something.
Fixes: for RSC-007, restore the file or correct the path — and watch case, because paths inside an EPUB are case-sensitive, so Map.PNG and map.png are different files even if your desktop OS pretends otherwise. For RSC-001, delete the stale <item> from the manifest or put the file back at the declared path.
Every content document a reader can land on must be in the spine — the ordered list that defines the book's reading order. RSC-011 means a hyperlink, TOC entry, or landmark targets a document that exists in the archive, is even declared in the manifest, but isn't in the spine. Add the document to the spine, or repoint the link at one that is.
EPUB 3 requires each content file to declare certain features it uses, via a properties attribute on its manifest entry: svg if the file contains inline SVG, scripted for JavaScript, mathml for math markup, remote-resources if it loads anything from the network. OPF-014 tells you a file uses one of these without declaring it — the message names the missing property. The fix is one attribute: find the file's <item> in the manifest and add properties="svg" (or whichever value the message names).
Every EPUB carries a unique identifier — an ISBN, or just a UUID (a Kindle ebook needs no ISBN; a random unique string is fully valid). The package file points at it: <package unique-identifier="uuid_id"> must match a <dc:identifier id="uuid_id"> element. OPF-030 means that pointer is dangling — the ID was renamed or the element deleted, usually by an editing tool. Make the two values match exactly.
NCX-001 is the same disease in a different organ. If the book includes a legacy toc.ncx (EPUB 2's table of contents, still shipped by most tools for older-reader compatibility), the NCX carries its own copy of the identifier in <meta name="dtb:uid"> — and it must be byte-identical to the package identifier. The mismatches are maddeningly small: a urn:uuid: prefix present in one and not the other, stray whitespace, or a tool like Calibre regenerating the package ID while leaving the NCX untouched. Copy one value over the other, character for character.
This pair probably catches more hand-fixed EPUBs than anything else on the list, because it punishes the most natural debugging move there is: unzip the EPUB, fix something, zip it back up.
An EPUB is a ZIP archive with one non-negotiable quirk. The EPUB specification requires — these are hard MUSTs in section 4.3.3 of EPUB 3.3 — that the archive's first entry be a file named mimetype, containing exactly the string application/epub+zip in US-ASCII, with no leading or trailing whitespace, no byte-order mark, stored uncompressed, and with no extra field in its ZIP header. That last clause is the silent killer: most ZIP tools write timestamps and other metadata into an "extra field" without asking. Finder's Compress, Windows' Send-to-Compressed-Folder, and a plain zip -r all produce archives that violate at least one of these rules — PKG-006 if mimetype is missing or not first, PKG-007 if it's compressed or its content is off by so much as a trailing newline (a stray extra field fires its own sibling code, PKG-005).
The fix is to rebuild the archive in the right order, with the right flags:
# step 1: mimetype first, stored (-0), no extra fields (-X)
zip -X0 book.epub mimetype
# step 2: everything else, added (-g) with normal compression
zip -rg book.epub META-INF OEBPS(Adjust OEBPS to whatever your content folder is called, and run this from inside the unzipped book's folder — zipping the parent folder is its own classic mistake, since it nests everything one level too deep and triggers RSC/OPF errors on top.) Alternatively, sidestep the whole trap: edit the EPUB in place with Sigil, which repackages the container correctly on save.
One more container code you may meet on files that passed through InDesign or old DRM tooling: PKG-026, which means the encryption metadata declares font obfuscation for something that isn't a font. Unless you deliberately obfuscated fonts, the fix is deleting the offending entry from META-INF/encryption.xml.
Here's the part the error-code lists never give you, and where most advice is secondhand and partly wrong. The stores do not enforce the spec equally — here is what each one's documentation says, plus the field behavior it doesn't document (all checked July 2026):
Two practical consequences. First, "it uploaded fine to KDP" is not evidence your EPUB is valid — it's evidence Amazon's converter coped. The failure shows up months later when you push the same file to Apple or a library channel and it bounces. Second, the reverse also happens: authors on Amazon's own forums report files that pass EPUBCheck cleanly and still fail KDP's conversion, because passing validation and surviving format conversion are different tests. The only strategy that covers every store is the boring one: fix every EPUBCheck error before uploading anywhere, then treat each store's converter as a separate hurdle.
And KDP has a third path the others don't: quality enforcement after publication. Broken internal links that survive upload don't vanish — Amazon's content-quality guide makes link correctness the author's responsibility, and reader complaints about defects like dead links can trigger a quality notice on a book that's already selling. An error tolerated at the gate can still cost you later.
Reading back over that list, notice what nearly every error has in common: none of them are writing problems. They're bookkeeping problems — two copies of an identifier drifting apart, an inventory out of sync with a folder, a ZIP tool's default flags. Bookkeeping is what programs are for, which is why our answer to "how do I fix these?" is: build files where they can't occur.
When we built EbookFormatter's generator, we didn't bolt a validator onto the end — we made the error classes structurally impossible. The generator writes the mimetype entry first, stored, with a bare ZIP header — no extra fields — so PKG-005, PKG-006, and PKG-007 can't fire. It mints one UUID per book and writes it into the package's dc:identifier and the NCX's dtb:uid from the same string, so OPF-030 and NCX-001 mismatches can't exist. The manifest and the archive are built in the same pass from the same data, so for everything the generator emits, every declared file exists and RSC-001 and RSC-007 have nothing to catch. The navigation document is declared with properties="nav", the cover with properties="cover-image", and the table of contents links to whole chapter files written in that same pass — there are no fragment links to break, so RSC-012 has no way in.
That's the honest pitch for a markdown workflow, and it applies whatever tool you use: an EPUB assembled by one process from one source is consistent by construction, while an EPUB edited by hand — or passed through a chain of converters — accumulates exactly the mismatches this page catalogs. If your manuscript is in plain text, you can skip the whole fixing loop: structure your markdown manuscript with headings and page-type annotations, and convert your markdown to EPUB in one step. If you're deep in a broken file instead, our guide to converting markdown to EPUB covers what breaks on Kindle across the other common conversion routes, Pandoc and Calibre included.
It's EPUBCheck's generic markup-violation error — a file inside the EPUB breaks the format's schema rules. The code is a category; the diagnosis is in the sub-message that follows it, which names the real problem (a duplicate id, an element not allowed at that position) plus the file, line, and column. Fix what the sub-message says, at the location it points to.
Amazon doesn't say — its validation pipeline is undocumented. Observably, KDP rejects some files with EPUBCheck-style codes but accepts many files EPUBCheck flags, because its converter repairs or ignores what doesn't break the conversion to Kindle's internal format. Passing EPUBCheck is neither required by KDP nor a guarantee of acceptance — but it's still the right pre-upload check, because it's the standard every other store holds you to.
Use Draft2Digital's free web validator (draft2digital.com/book/epubcheck/upload), which runs EPUBCheck on any file you upload — the old IDPF web validator is dead, and there's no official replacement. For a local no-command-line option, the pagina EPUB-Checker wraps EPUBCheck in a desktop app.
Usually. Warnings don't make the file invalid — errors and fatals do. Apple requires a clean EPUBCheck pass, Kobo lets non-critical issues through, and OverDrive is the zero-tolerance outlier. Clear every error; read the warnings and use judgment.
Apple requires every submission to pass the current EPUBCheck; Amazon converts your file to its internal format and tolerates errors its converter can absorb — broken fragment links (RSC-012) being the commonly reported example. Same file, different gates. Validate before uploading anywhere and the difference stops mattering.
The mimetype rule. That file must be the archive's first entry, uncompressed, with no ZIP-header extra fields — and ordinary ZIP tools violate this by default. Rebuild with zip -X0 book.epub mimetype followed by zip -rg book.epub META-INF OEBPS, or edit in Sigil, which packages correctly on save.
Or skip the fixing entirely. If your book lives in plain text, you never need to meet these errors: write in markdown, then format your book into a valid, Kindle-ready EPUB in seconds — free, no account. New here? Start with the Formatting Guide or browse our guides.