A KDP EPUB’s nav.xhtml should be created from the final body order, then audited until every href resolves to the intended chapter file. In this sample, a visible TOC remained as a separate book page while only four body chapters entered nav.xhtml. The four hrefs resolved to four distinct body files, so the article-specific Stage 4 result is passed for local structure. Tap behavior in KDP or on a reading device remains a separate test.
Connect four nav.xhtml hrefs to four body chapters
nav.xhtml is the EPUB navigation document. Under the EPUB 3.3 specification, navigation marked with epub:type="toc" provides the primary table of contents. Avoiding reader confusion requires more than the presence of a list: the entries must follow reading order, and each href must resolve to the correct chapter.
This article does not center on why a visible TOC page and a device menu have different roles. It focuses on the generated nav.xhtml file itself and on resolving four links to four body files.
Separate one visible TOC file from four body files
The sample contained one visible TOC file and four body chapters. The visible TOC carried four comparison markers, while the four body files contained twelve fixed markers in total. The expected nav.xhtml contained only the four body chapters; the visible TOC file was not itself a navigation item.
The starting values were:
- one visible TOC file with four comparison markers;
- four body chapter files;
- four expected nav.xhtml entries;
- four distinct body-file hrefs; and
- twelve fixed markers across the body files.
Keeping the visible page in the book and including it in logical navigation are separate choices.
Build nav.xhtml, then resolve every target
First, finalize the order and authoritative headings of the four body chapters. Decide whether the visible TOC belongs in logical navigation and generate the EPUB. In the unpacked nav.xhtml, find the epub:type="toc" list and record item count, label, order, and href.
Resolve every href relative to nav.xhtml. Confirm that the target XHTML exists and contains the expected body marker. Similar-looking filenames do not count if a relative path is broken or points to the wrong chapter. Finally, review Amazon KDP’s supported manuscript formats and activate all four items in Kindle Previewer or on the target device.
The local run verified four distinct hrefs
In the dedicated test workspace, I selected the visible TOC and four body chapters, then excluded the visible TOC from generated navigation with --exclude-from-toc 1. I set the series and volume data, reviewed the export plan, generated the EPUB, and inspected nav.xhtml, NCX, and the body XHTML. The evidence records a command_count of 9.
The output was valid=true, with a spine count of 8 and zero missing images. Nav and NCX were present with four entries each. The nav.xhtml hrefs were p002.xhtml, p003.xhtml, p004.xhtml, and p005.xhtml, with no duplicates. Four visible-TOC markers and twelve fixed body markers were found. The four hrefs matched the four expected body files.
This passes nav.xhtml creation and local target inspection. It does not pass device-menu rendering or tap behavior.
Return to the broken href or source mapping
KDP acceptance, Kindle Previewer or hardware menus, operation of the four links, and rendering across all reading systems remain unverified. Use the failure to choose the recovery point:
- If nav does not contain four items, return to TOC inclusion and the exclusion setting.
- If href order differs from the four body chapters, return to source-file ordering.
- If two hrefs are identical, return to chapter-to-output-file mapping.
- If a target XHTML is absent, return to the export plan and package inclusion.
- If a target contains the wrong body marker, return to the chapter heading and source-file mapping.
- If a link fails on a device, record that as a separate external result rather than rewriting the local pass.
Rune Studio generates an EPUB that includes nav.xhtml
The current macOS Rune Studio EPUB 3 wizard supports source files, chapter order, TOC inclusion, metadata, and export-plan review. Its output includes the EPUB navigation document, NCX, package document, and body XHTML. These are Stage 3 product capabilities documented on the Rune Studio product page and in the product reference.
The four entries, four distinct hrefs, four visible-TOC markers, and twelve fixed body markers are Stage 4 observations from this dedicated sample. The standard, documented product capability, measured output, and unverified external behavior remain separate.
Conclusion: resolve all four links before device testing
Create nav.xhtml from the final four-chapter order and verify each href against the corresponding body file. In this sample, the visible TOC was excluded as an item, and nav.xhtml pointed to four distinct files from p002.xhtml through p005.xhtml. The local structural result is passed. The next gate is to activate the same four entries in Kindle Previewer or on a target device and confirm the reader-facing navigation separately.
