A table of contents looks like the simplest page in a book: a list of chapters with the page each one starts on. It is also the page most likely to be quietly broken, because it is not one thing but two. In a printed book, the contents is a typeset page where each entry points to a fixed page number. In an ebook, it is a set of navigation links, with no page numbers at all, because an ebook has no fixed pages. A contents page that is perfect on paper can be useless on a Kindle, and the reverse — and the most common contents fault of all is treating the two as the same job.
So the first decision is not how to lay it out, but to recognise that you are building two related things for two different objects. Let us take them in turn, then look at the choice between making the contents by hand and letting it generate itself, and finally at the reasons it breaks. The contents is one of the last pieces to fall into place in how to format a book interior for KDP, because it depends on everything above it being settled first.
The print contents: a typeset page
In a printed book, the contents page is part of the front matter, usually the last major piece before the book begins — its place in the running order is set out in front matter and back matter: what goes where. It lists the parts of the book a reader might want to turn to: chapters, named sections, sometimes major subsections, and the back-matter pages like an index or acknowledgements.
Each entry has two halves — the title on the left, the page number on the right — joined either by a row of leader dots or simply by the space between them. The conventions are gentle: align the page numbers in a clean right-hand column, keep the type quiet and consistent with the rest of the front matter, and do not list every minor subheading, which turns a useful map into a wall of text. A novel's contents might be five lines; a textbook's might run to two pages. Either is fine, as long as it helps a reader find their way rather than reproducing the whole structure.
The one thing a print contents must be is accurate. Every page number has to match where the chapter actually falls — which is why the contents is generated near the end of the work, after the chapters, the front matter and the margins are all settled, not while pages are still moving around.
The ebook contents: navigation, not page numbers
An ebook has no fixed pages. The reader can change the font size, the screen size, the margins — and the text reflows, so "page 52" means nothing. A printed contents page transplanted into an ebook, with its column of now-meaningless page numbers, is at best useless and at worst a reason a file is flagged on upload.
What an ebook needs instead is navigation: a list where each entry is a link that jumps the reader straight to that chapter, with no page numbers at all. There are usually two layers of this. One is a contents page the reader sees, set as a list of links near the front of the book. The other is the device's built-in navigation — the menu a reader summons to jump around — which is driven by a hidden structure in the file. On EPUB files this navigation has historically been carried by an NCX (the "Navigation Control file for XML") and, in modern EPUB, by a nav document; the names matter less than the fact that it exists separately from the visible page and has to be present for the reader's "go to chapter" menu to work at all.
The practical upshot: a good ebook contents is built from the book's actual structure, so the visible links and the hidden navigation agree, and neither carries a page number. Get this right and a reader can move through the book on any device. Get it wrong and the contents either does nothing when tapped or fails to appear in the navigation menu.
Manual or automatic?
This is the choice that decides how much grief a contents page causes you.
A manual contents is one you type and maintain by hand: you write each chapter title, look up the page it falls on, and enter the number. It is entirely workable for a short book that is finished and will not change. Its weakness is obvious — the moment a chapter title changes, or an edit shifts the pages, every number after the change is wrong, and nothing tells you. A manual contents is only ever as current as the last time you checked it against the book, by hand, line by line.
An automatic contents is generated from the book's own structure — its chapter and heading styles — so the entries and their page numbers are read from where the chapters actually are. Change a title, add a chapter, reflow the text, and the contents updates to match. This is how published books are made, because it removes the single largest source of contents error: human bookkeeping that falls out of date.
The automatic approach also solves the print-versus-ebook problem in one move. Because the contents is built from the structure rather than typed by hand, the print version can show page numbers and the ebook version can show links — the same source, two outputs.
Why a table of contents breaks
When a contents page goes wrong, it is almost always one of these:
- Stale page numbers. A manual contents that was not updated after an edit, so the numbers point to the wrong pages. The cure is an automatic contents, or a disciplined final check after the book is locked.
- Page numbers in an ebook. A print contents pasted into an ebook, where the numbers are meaningless and can cause the file to be flagged. The ebook contents should be links only.
- Missing navigation in the ebook. A visible contents page exists, but the hidden navigation structure does not, so the device's "go to chapter" menu is empty. Both have to be present.
- Links that point nowhere. An ebook contents whose links were never anchored to the chapters, or were anchored before the chapters moved, so tapping an entry does nothing or lands in the wrong place.
- Listing too much, or too little. A contents that reproduces every minor subheading becomes a wall; one that omits major sections fails as a map. List the levels a reader would actually navigate to, and stop.
- Building it too early. Generating the contents while pages are still shifting, so it is wrong by the time the book is final. The contents is one of the last things to settle.
Read down that list and the same root cause keeps surfacing: a contents page that was built or maintained separately from the book it describes, so the two drifted apart. The whole craft of a contents page is keeping it tied to the structure it points into — accurate folios in print, working links in the ebook, and never a number where a link belongs. Do that, and the humble list at the front of the book quietly does its job: it lets a reader find their way, on paper or on a screen, without ever noticing the page that sent them there.
Where Folio Format fits
The same source, two outputs, is the model Folio Format follows: the contents is generated from the book's chapters and headings, so the print contents carries accurate folios and the ebook contents carries working links and navigation, without you maintaining two lists by hand. The studio keeps the contents tied to the structure it points into rather than typed beside it. It is designed to help you export KDP-ready files and catch common publishing issues before upload, and a contents that is out of step with the book is one of the easiest issues to ship by accident and one of the most visible once a reader hits it.
Last checked 26 May 2026. Always confirm current Amazon KDP and IngramSpark specifications before uploading final files. Folio Format is designed to help users export KDP-ready files and catch common publishing issues before upload; it makes no claim about platform acceptance.