Does Your Self-Published Ebook Need a Table of Contents?

Yes. Every self-published ebook needs a table of contents, and most platforms expect two distinct types: a logical TOC that powers the device navigation menu (such as Kindle’s “Go To” list) and an inline HTML TOC that appears as a clickable page inside the book. Apple Books requires one outright, the EPUB standard itself makes one mandatory, and Amazon treats the second as strongly recommended.

What Is the Difference Between a Logical TOC and an HTML TOC?

A logical TOC is a machine-readable navigation structure stored in the ebook file; an HTML TOC is a visible page of clickable links inside the book that readers can see and tap. They serve different purposes and are built differently, but a well-made ebook includes both.

The logical TOC (sometimes called a “navigational TOC” or “device TOC”) is what reading apps and e-readers use to populate their built-in navigation menus. On a Kindle, it powers the “Go To” menu; on Apple Books, it fills the table of contents sidebar; on Kobo devices, it drives the built-in chapter navigation. Readers never see this structure as a page in the book. It lives in the EPUB’s NCX file (for EPUB 2) or in the Navigation Document’s toc nav element (for EPUB 3).

The HTML TOC, by contrast, is a regular page in the ebook’s content flow. It typically appears near the front of the book, after the title page, and contains clickable links to each chapter or section. Amazon’s Navigation Guidelines describe the two as doing different jobs: the logical TOC is reachable from any page through the Kindle menu, while the HTML TOC “has a location” that a reader has to travel to.

The failure most often seen in files sent to ebookpbook for repair is having one layer without the other. A visible contents page with no logical TOC leaves the device’s navigation menu empty; a logical TOC with no visible page leaves a reader scrolling from the title page into chapter one with no sense of how the book is shaped.

What Does Each Ebook Platform Require?

Every major ebook retailer requires or strongly recommends an ebook table of contents, though the wording and the strictness vary. The table below summarises the position each platform publishes, followed by the detail that matters when you are building the file.

Amazon KDP

KDP is the most explicit. Its Navigation Guidelines state that the logical TOC “is especially important for books that are longer than 20 pages”, and set out four rules for the HTML TOC: place it toward the beginning of the book rather than the end, make every entry a real HTML link, do not build it with <table> tags, and do not include page numbers. Amazon also notes that incorrect placement affects the accuracy of the “Last Page Read” feature, and that correct placement is what puts the contents page into the free sample readers download before buying. Kindle devices and applications support two levels of nesting, and Amazon requires the entries to run in the same order as the book.

Apple Books

Apple is the strictest of the five. The Apple Books Asset Guide states plainly that “a table of contents is required for all books”, built as a nav element with an epub:type value of toc. Apple also asks you not to put page numbers against the entries, because Apple Books calculates positions itself to suit the reader’s font and screen size. A second structure, landmarks, is required for fixed-layout books unless you supply a custom sample.

Kobo

Kobo publishes its EPUB requirements as an open specification. That Kobo spec explains the mechanism rather than issuing a rule: for EPUB 2 files, Kobo populates the contents menu from the navMap element of the NCX, and for EPUB 3 files from the toc nav element. The consequence is the part worth remembering. If the NCX is missing, Kobo falls back to the OPF spine, so readers get a menu built from the file names and reading order rather than from your chapter titles. Kobo does not insist on a particular file name for either structure.

Draft2Digital

Draft2Digital takes a more hands-off approach, and which way it goes depends on what you upload. Supply a Word manuscript with consistent heading styles and D2D’s conversion engine builds a working table of contents and inserts page breaks between chapters for you. Supply a finished EPUB and D2D passes it through without editing it, which means TOC quality and compliance are entirely yours to get right.

IngramSpark

IngramSpark’s requirement is indirect but binding. Its current File Creation Guide (version dated 24 August 2026) states “Format: EPUB 3.0 required” and that all EPUBs must be compliant with the most up-to-date validation. Since a valid EPUB 3 file cannot exist without a Navigation Document, a working logical TOC is part of IngramSpark’s technical acceptance criteria whether or not it is listed as its own line item.

How Do EPUB 2 and EPUB 3 Handle Navigation Differently?

EPUB 2 uses a DAISY NCX file (Navigation Control for XML) built from navPoint elements. EPUB 3 replaced it with a Navigation Document: a standard XHTML file containing an HTML5 nav element carrying the attribute epub:type="toc". The differences between EPUB 2 and EPUB 3 matter here more than almost anywhere else in the file, because EPUB 3 turns navigation into ordinary markup you can read, edit and style.

In EPUB 3 the navigation layer is not optional. The W3C EPUB 3.3 specification calls the navigation document “a mandatory component of an EPUB publication”, and requires that a valid one “MUST include exactly one toc nav element”. Exactly one: not zero, and not two competing versions left behind by different tools.

You can still include an NCX alongside the Navigation Document for older reading systems, but it is a courtesy to legacy devices rather than a second table of contents. If you include both, keep them in step; a stale NCX left over from an earlier export is a common source of two different chapter lists inside one file.

Kindle devices and applications support two levels of nesting in the logical TOC. Chapters as top-level entries with sections nested beneath them will work; a third level will be flattened. Keep that ceiling in mind if your book has parts, chapters and sub-sections, and decide which two levels earn the space.

Does Accessibility Law Now Require a Table of Contents?

For some sellers, yes. The European Accessibility Act came into force on 28 June 2025 and applies to ebooks sold in the European Union. The Alliance of Independent Authors’ guide to the EAA lists clear navigation among the requirements for a compliant ebook, putting it plainly: “Navigation in the book needs to be easy and clear, so tables of contents must be accurate and complete.”

The exemption matters as much as the rule. Microenterprises, defined as businesses employing fewer than ten people or turning over less than two million euros a year, are outside the Act’s scope, which covers most self-published authors writing under their own name.

The practical pressure still applies. The retailers and platforms selling your book are also covered, and ALLi notes that stores, libraries and platforms may begin refusing non-compliant files. A book rejected on accessibility grounds is unavailable to every reader, not only to readers with disabilities. An accurate table of contents is the cheapest item on the accessibility list, which is a good reason to treat it as settled rather than optional. Our guide to making an accessible ebook covers the rest of the checklist.

How Do Formatting Tools Handle Your Table of Contents?

How your ebook table of contents gets created depends on which tool you use to format and export the file, and the behaviour varies enough to catch people out.

If you write in Microsoft Word and upload to KDP, or convert with Calibre, the TOC depends entirely on your heading styles. Word’s built-in heading styles (Heading 1, Heading 2 and so on) are what conversion tools read to build the logical TOC. Format your chapter titles by hand with bold text and a larger point size instead, and most converters will not recognise them as chapters at all; the resulting ebook has no navigation structure. Amazon’s own instructions for Word take the same route: apply Heading 1 to chapter titles, insert the table of contents from the References tab, then clear the “Show page numbers” box.

Dedicated formatting tools such as Vellum, Atticus and Kindle Create build both layers automatically from the chapter structure you define inside the tool. That is one of their main advantages over a manual Word-to-EPUB route.

Draft2Digital’s conversion engine likewise generates a TOC from consistent heading styles. As noted above, uploading a finished EPUB bypasses that entirely. The same principle governs Amazon’s EPUB-to-Kindle conversion: Amazon rebuilds the Kindle navigation from whatever your file already contains, so a gap in the source is a gap in the finished Kindle book.

What Happens If You Skip the Table of Contents?

Omitting the ebook table of contents creates problems that range from inconvenient to distribution-blocking, and they differ by platform.

On KDP, a missing logical TOC means the Kindle “Go To” menu shows no chapter list. Readers cannot jump to a chapter; they can only scroll or drag the progress bar. A missing HTML TOC has a commercial cost as well, because Amazon states that correct placement of the contents page is what makes it appear in the free sample, and the sample is where a browsing reader decides.

On Kobo, nothing breaks outright, which is what makes the fault easy to miss. Kobo simply falls back to the OPF spine, so the contents menu fills with entries derived from your file structure rather than your chapter titles. The book opens, sells and reads; the navigation just looks like it was assembled by a machine, because it was.

On IngramSpark, an EPUB 3 file without a valid Navigation Document will fail validation and can be rejected at upload. Since IngramSpark is the route to thousands of retailers and library systems, a rejected file blocks the widest distribution channel available to an indie author.

There is a plain reader-experience cost too, worth stating without exaggeration. Non-fiction without a contents page is harder to use, because those readers move around rather than reading straight through; fiction suffers less. Either way the fault stays in the file until you re-upload, and the fix takes minutes.

How Should You Adapt a Print TOC for an Ebook?

A print-style table of contents does not translate directly to an ebook. Three specific adjustments are needed.

First, remove page numbers. Reflowable ebooks have no fixed pages; the text reflows to the reader’s font size, screen size and margins. An entry reading “Chapter 3 ………….. 47” is meaningless because there is no page 47 to go to. Both KDP and Apple say the same thing here, and Apple explains why: the reading system works out positions itself so that they stay correct at any text size.

Second, make every entry a clickable hyperlink. In a print book the TOC is a reference list; in an ebook it is the navigation. Each chapter title has to be an anchor link pointing at the right location in the file. KDP puts it bluntly: a table of contents that is not made of links “is not useful on Kindle”. If your links point to the wrong chapters, our guide to fixing broken ebook hyperlinks covers the usual causes.

Third, do not use HTML table elements for layout. Some authors reproduce the print dot-leader look with an HTML table. KDP warns against it directly, on the grounds that tables are for tabular data rather than layout; table-based rows also break awkwardly on narrow screens and interfere with reading-system accessibility features. A plain ordered or unordered list of linked chapter titles is the most reliable structure across every device and platform. If you want the indented look of a print contents page, Amazon’s own recommendation is to indent nested entries with a CSS margin rather than a table.

Frequently Asked Questions

Does a short ebook or novelette still need a table of contents?

Yes. Even a short ebook benefits from a logical TOC so that reading apps can display the book’s structure in their navigation menus. KDP describes a logical TOC as especially important for books longer than 20 pages, and Apple requires a table of contents for all books regardless of length. A contents page also helps readers return to specific sections on re-reads.

Can I put my HTML table of contents at the end of the ebook instead of the beginning?

You can, but KDP advises against it. Its Navigation Guidelines say to place the HTML TOC toward the beginning of the book rather than the end, so that a reader paging through from the start meets it naturally. Amazon also states that incorrect placement affects the accuracy of the “Last Page Read” feature and that correct placement is what makes the contents page appear in the book’s free sample.

Will Amazon build a table of contents for me if I upload a Word file?

KDP’s conversion can generate a logical TOC from a Word document, but only if you used Word’s built-in heading styles for your chapter titles. If you formatted chapter titles by hand with bold text and font size changes, the converter will not read them as structural headings, and the resulting Kindle book will have no navigation. Amazon’s own Word instructions are to apply Heading 1 to each chapter title, insert the table of contents from the References tab, then clear the “Show page numbers” option.

What is the difference between an NCX file and a Navigation Document?

An NCX (Navigation Control for XML) file is the EPUB 2 method for defining a table of contents, using navPoint elements in an XML structure. A Navigation Document is the EPUB 3 replacement: an XHTML file containing a nav element typed as epub:type="toc". EPUB 3.3 requires exactly one toc nav element in a valid navigation document. You can include an NCX as well for older reading systems, but keep the two in step, because a stale NCX is a common cause of two conflicting chapter lists in one file.

How many levels of nesting should my ebook table of contents have?

For most books, one level (chapters only) or two levels (parts and chapters, or chapters and major sections) is enough. Kindle devices and applications support two levels of nesting; anything deeper is flattened. If your book has parts, chapters and sub-sections, decide which two levels a reader would actually navigate by rather than mirroring the full hierarchy.

Do I need both a logical TOC and an HTML TOC, or will one do?

Build both. They are read by different things and neither substitutes for the other: the logical TOC feeds the device menu, and the HTML TOC is the page a reader scrolls to. In EPUB 3 you can generate both from the same toc nav element by also placing it in the spine, though Amazon recommends keeping the toc nav element in a separate file from the visible contents page.