Navigation is the first thing a reader touches and the first thing they complain about. A contents entry that scrolls to the last line of the previous chapter, a Kindle Go To menu with nothing in it, a box set where book four cannot be reached: each of those is a one-star review waiting to be written. We build the navigation properly and prove every link.
A clickable table of contents is not a page. It is two or three separate things that readers and software confuse constantly. There is the navigation file the reading system consumes, there is the contents page a reader can turn to like any other page, and there are the landmarks that tell a device where the book properly begins.
The navigation file is the one that matters most and the one almost nobody looks at. In EPUB 3 it is the nav document, an XHTML file with an ordered list marked with a navigation role. In older EPUB 2 files and on a good deal of Kindle hardware still in daily use, the same job is done by the NCX. Ship both and every device has something to read.
The inline contents page is the human-facing one. It can be styled, it can carry a title, and readers scroll to it. It is not a substitute for the navigation file, though converters routinely produce one while leaving the other empty, which is exactly how a book ends up with a blank Go To menu.
Authors send us books where the contents page looks immaculate and the device menu offers nothing. The cause is almost always the same. The contents page was typed by hand as a list of styled paragraphs, and no navigation file was ever generated from real headings.
Software builds navigation from structure, not from appearance. A line of 18pt bold centred text is, as far as the machine is concerned, a paragraph. Until a chapter title is marked as a heading, nothing downstream can find it.
Visual weight carries no meaning in markup. The chapter title has to be tagged as a heading before any tool, retailer or screen reader can recognise it as one.
Devices build their menus from the navigation file. If it is wrong, correcting the visible contents page changes nothing at all.
A link can be perfectly valid and still land in the wrong place, because it points at the file rather than at the exact line the chapter starts on.
This is a narrow service and it is priced accordingly. Every item below is navigation work. We are not restyling your interior, and you are not paying for a rebuild you did not ask for.
Written as a proper XHTML navigation document with the correct epub:type, an ordered list, and one entry per real heading in the book. Retailers parse this file directly, and Apple Books in particular will refuse a package where it is missing or malformed. It becomes the spine of every menu a reader ever opens.
Deprecated in EPUB 3 and still read every day by Kindle hardware and older reading apps that people have not replaced. It costs a few kilobytes and it is the difference between a working contents list and an empty one on a device bought five years ago. We ship it alongside the nav document, matched entry for entry.
The page a reader turns to inside the book, styled to match your interior rather than dropped in as raw default text. Chapter titles, part divisions and any subtitles you want carried through, each one a live link that has been opened and confirmed. Positioned in the front matter where the retailers expect it.
Before any navigation can be generated, the chapter openers have to be real headings. We convert styled paragraphs into a proper heading hierarchy across the whole manuscript, which is the underlying fix almost every broken contents list actually needs.
The landmarks list tells a device where the cover is, where the contents page sits, and where the body of the book begins. Set correctly, a reader opening your book arrives at chapter one rather than at the copyright notice.
Every entry in every navigation surface is opened on a real device and confirmed to land on the chapter title itself. This is slow and it is the whole point of the service. A link that resolves to roughly the right area is a link that is broken.
Navigation work rarely photographs well, because when it is right it is invisible. These are the surfaces we build and the screens we prove them on.
Depth is the only real design decision in a contents list, and getting it wrong makes the book harder to use rather than easier.
One entry per chapter, in order, with nothing beneath it. The list fits on a single screen on a phone, the reader can scan it in two seconds, and there is no expanding or collapsing to think about.
This is correct for almost all fiction and most narrative nonfiction. If your chapters are named and numbered, a flat list is not a compromise. It is the right answer, and adding levels to it would only bury the chapters the reader is actually looking for.
Parts containing chapters, or chapters containing named sections. The nav document carries a nested ordered list, and reading systems that support hierarchy will show it as an expandable tree.
Right for textbooks, manuals, reference works and anthologies where a reader arrives looking for one specific thing. Wrong for a novel. Past three levels the list stops being navigable on a phone screen, and we will tell you when you have crossed that line.
Nearly every job that reaches this desk is one of these six. They are all cheap to fix and all expensive to leave alone.
A finished book carries more navigation than most authors realise. Each surface below is built, populated and tested separately, because a device will happily read one and ignore another.
| Element | How we build it | Why it matters |
|---|---|---|
| EPUB 3 nav document | An XHTML file carrying an ordered list marked epub:type="toc", with one anchor per real heading and no styled paragraphs mistaken for chapters. | This is the file retailers validate and reading systems parse. If it is malformed, Apple Books rejects the package outright rather than warning you about it. |
| NCX navigation map | A parallel navMap with matching playOrder and text labels, declared in the manifest and referenced from the spine's toc attribute. | Older Kindle hardware and a long tail of reading apps ignore the nav document entirely. Without the NCX, those readers get no contents list at all. |
| Inline contents page | A styled XHTML page in the front matter, listed in the spine, with live anchors to each chapter and typography that matches the rest of your interior. | This is the page a reader actually turns to and screenshots. It also satisfies retailers that expect a visible contents list in the first few pages. |
| Landmarks list | A second nav element marked epub:type="landmarks", declaring the cover, the table of contents itself, and the bodymatter start point. | Determines where a book opens on first launch. Set it and the reader lands on chapter one. Leave it out and they land on your copyright page. |
| Heading hierarchy | Real h1 to h3 elements applied across every content document, with the hierarchy reflecting the actual structure rather than the point size. | Every navigation surface is generated from this. Get it wrong and everything downstream inherits the mistake, including screen readers. |
| Fragment anchors | Each navigation link points at an id on the heading element itself, not merely at the filename of the chapter document. | Pointing at a file means landing wherever the reading system decides to begin rendering, which is frequently the wrong line by half a screen. |
| Kindle Go To menu | Verified in Kindle Previewer and on hardware, confirming that the menu populates and that Beginning and Cover both resolve. | Amazon builds this menu from your navigation files. It is the most-used navigation surface on the biggest store, and converters routinely leave it blank. |
| Page list | An optional nav element mapping print page breaks to positions in the text, exposed so library systems and citations can reference real pages. | Academic buyers and library aggregators increasingly require it. Without it, a scholar citing your eBook has no page number to cite. |
We do not test navigation by looking at it. We test it by tapping it, on each of these, one entry at a time.
A Paperwhite and an older Kindle, because the older device is the one that still needs the NCX. We open the Go To menu, tap through every entry, and confirm the Beginning marker resolves to chapter one rather than to the title page.
Apple validates the nav document more aggressively than any other retailer and will reject a package that Amazon accepts without comment. We open the contents pane, expand every nested level, and confirm the hierarchy renders as built.
The screen where a deep nested list stops being usable. We check that the list is scannable at phone width and that no entry has wrapped into an unreadable ribbon of text.
The reference implementation for the NCX and the environment most library systems are built on. If the fallback navigation is broken, this is where it announces itself first.
Automated confirmation that the nav document is well-formed, that every anchor resolves to an id that exists, and that no link points at a file the package does not contain.
VoiceOver reading the navigation aloud, confirming that entries are announced as a list rather than as loose text, and that a reader navigating by structure can move chapter to chapter.
You get working files and the evidence that they work. Nothing is left for you to check.
Your book back, with the nav document written, the NCX matched to it, landmarks declared and the inline contents page styled to your interior. Everything else in the file is left exactly as we found it, because you did not ask us to touch it.
The same corrected navigation delivered in the format Amazon ingests, confirmed in Kindle Previewer with the Go To menu populated and every entry resolving. Upload it as it stands.
A written list of every navigation entry in the book, which surface it appears on, and confirmation that it was opened and landed correctly. If we found a heading that should not have been in the list, it is noted with the reason.
The nav document, the NCX and the contents page as plain readable files, so you or any future supplier can see exactly what was built rather than guessing at it.
If your headings were styled paragraphs, we can hand back the manuscript with a real heading hierarchy applied, so the next edition starts from a document that generates navigation on its own.
Two paragraphs on what was wrong, what we changed, and what to avoid doing in the next book. Useful if you plan to keep writing, which you presumably do.
Five steps, most of them quick. The slow one is the last one, and it is the one you are paying for.
Any format: EPUB, Word, a Kindle file, or a book already on sale that misbehaves. Tell us whether you want a flat chapter list or nested levels, and if you are not sure we will look at the structure and recommend one.
We open the package and read the nav document, the NCX and the spine. This usually takes twenty minutes and it usually explains the whole problem, because in most files at least one of those three is empty.
Styled paragraphs become real headings, the hierarchy is set to match the book's actual structure, and front matter that should not be listed is excluded rather than deleted.
Nav document, NCX, landmarks and the inline contents page, each built from the same repaired hierarchy so that no two of them can disagree with each other.
One entry, one tap, one confirmation that the chapter title is the first thing on screen. Across the devices listed above. This is the part nobody else does, and it is why files leave here working.
Priced on word count, because length is a fair proxy for the number of headings, anchors and links that have to be built and then opened one at a time. The structure inside the book adjusts it from there.
Required steps are marked with *. Optional extras can be removed from the summary with the cross icon.
What kind of book it is, which tells us how deep the navigation is likely to need to go.
Total word count including front and back matter, since both can carry navigable entries.
Which navigation surfaces you want built and which output files you need them in.
How much structure sits inside the book. Sub-levels, parts and named sections all add entries and anchors.
Only relevant if figures, plates or maps need their own navigable entries.
Standard allows time for the full link-by-link pass. The faster tiers move you up the queue without shortening that pass.
Two rounds are included. More are for books where the chapter structure is still being argued about.
This buys navigation and nothing else. Editing, proofreading, interior styling, cover artwork, ISBN registration and uploading to your retailer accounts are outside it. If your interior also needs work, we will say so rather than quietly billing for it.
Every converter on earth will produce something it calls a table of contents. Here is what the two approaches actually hand your reader.
| What you are comparing | Auto-Generated Navigation | Book Formatting Experts |
|---|---|---|
| Where a link lands | ✕ Somewhere in the vicinity of the chapter, because the anchor points at the file rather than at the heading. | ✓ On the chapter title, confirmed by a human tapping it on hardware before the file is handed over. |
| The Kindle Go To menu | ✕ Frequently empty, because the tool wrote a contents page and never generated the navigation files behind it. | ✓ Populated and tested in Previewer, with Beginning and Cover both resolving where they should. |
| Older Kindle devices | ✕ No contents list at all, because the NCX was skipped as deprecated and nothing replaced it. | ✓ NCX shipped alongside the nav document, matched entry for entry, so nothing is unreachable. |
| Front matter | ✕ Copyright page, dedication and epigraph all listed as if they were chapters, burying chapter one below the fold. | ✓ Excluded from the list by intent, present in the book, so the reader sees the book rather than the boilerplate. |
| Nesting | ✕ Everything flattened to one level, or every subheading promoted, with no judgement applied either way. | ✓ Depth chosen deliberately and tested on a phone screen, because a list nobody can scan is not navigation. |
| Evidence it works | ✕ None. You find out from a review that the contents list is broken, and by then it has a star rating attached. | ✓ A written verification sheet naming every entry and confirming it was opened and landed correctly. |
Depth, naming and landmarks change genre to genre. A structure that serves a textbook will actively obstruct a novel.
A flat list of chapters, named or numbered, and nothing beneath them. The reader is not searching, they are resuming, so the list exists to get them back to where they stopped. Scene breaks never get entries. The landmark that matters is the start-reading point, because a novel should open on its first line.
Readers of this genre skip, and the contents list is how they do it. Two levels: chapter, then the named sections inside it. Exercises, worksheets and summaries get their own entries because those are the pages people return to. A flat list here loses you the reader who bought the book for chapter seven.
Deep hierarchy, numbered sections, a page list mapped to the print edition, an index that links into the body text, and back-linked notes. Libraries and citation systems both depend on the page list. This is the most anchor-heavy navigation we build and the one where a missing entry is noticed fastest.
Every recipe is an entry, grouped by section, and readers arrive looking for one specific dish. A list of recipes as a second navigation surface is worth more here than in any other genre, because nobody reads a cookbook in order and the contents list is the whole interface.
The hardest navigation job we do. A master list at the top, each book as a collapsible level beneath it, and landmarks that let a reader jump to book four directly. Stitched-together box sets where only book one is reachable are the single most common complaint we are sent to repair.
Every poem or story is a chapter, which means a hundred entries where a novel has thirty. The list has to stay scannable on a phone, so grouping by section and careful title truncation matter more here than anywhere else. First lines are sometimes the only titles there are.
Automated validation tells you a link resolves. It cannot tell you the link resolves to the right place. EPUBCheck is perfectly content with an anchor that lands the reader four paragraphs into the previous chapter, because the anchor is well-formed and the target exists.
So a person opens every entry on a device and looks at what is on screen. On a hundred-chapter poetry collection that is a genuinely tedious afternoon. It is also the only way anyone has ever found to be certain, and it is the reason this service exists as a separate thing you can buy.
The contents list is an output, not an input. Repair the heading hierarchy and correct navigation follows from it. Edit the list directly and you have painted over the problem.
The NCX is officially obsolete and millions of working devices still read it before anything else. Obsolete in the specification is not the same as absent from the world.
Every level you add pushes the chapters further down. A sub-level has to earn its place by helping someone find something, and most of them cannot.
Each of these is confirmed on a device, not inferred from a validator.
This service exists because navigation fails on its own, in books that are otherwise fine. If any of these describe you, this is the only thing you need to buy.
The most common one-star complaint about a self-published eBook is not the prose. It is that the reader could not get back to where they were. A single review saying the contents list does not work costs more than fixing it does, and it never goes away.
You can see a contents page in your own book and Amazon's menu offers nothing. That means the navigation files behind the page were never built. It is a twenty-minute diagnosis and it is the most common thing we find.
Three or four finished books stitched into one file, with only the first reachable from the menu. Box set navigation is genuinely hard, and it is worth doing properly because box sets are read by your most committed readers.
One-click tools generate a contents list because they are supposed to, not because they understood your book. Nobody opens every link afterwards. The failures sit there quietly until a reader finds them for you.
Academic titles, reference works and anything a library might stock. Without a page list there is no way to cite the book, and an index with no links is decoration.
Files produced before EPUB 3 was widely supported, sitting on stores right now with an NCX and nothing else, or with navigation that broke when a retailer changed their ingestion rules and never told anyone.
Three commitments, and they are the ones the whole service stands on.
Not a spot check across a few chapters. Every entry, on every navigation surface, opened by a person on a device. The verification sheet lists them, so you can see exactly what was confirmed and count them yourself if you want to.
If a reader or a retailer finds an entry that lands in the wrong place, we fix it at no charge and it is not counted against your revision rounds. We opened it. If we got it wrong, that is ours to put right.
If your navigation is already correct, we will say so and charge you nothing beyond the look. It happens more often than you would expect, and pretending otherwise would be a poor way to run a business.
The contents list is not a formality. It is the mechanism by which a reader who put your book down picks it back up.
Most people read a book across a fortnight in twenty-minute pieces. Every time they come back, they touch the navigation. A contents list that fights them is friction applied at the exact moment they are deciding whether to continue.
Nobody emails you about a broken link. They write a review, it sits at the top of your product page, and every prospective buyer reads it. A navigation failure is the cheapest possible way to lose a sale you had already made.
A reader on book five will jump back to check a name from book two. If your navigation works, they stay in your series. If it does not, they go and read someone else's, and they do not tell you why.
Three ideas, applied to every book that comes through here.
Read the book's actual shape rather than the shape the styling suggests. Parts, chapters, sections, apparatus. What a reader would want to jump to, and what they never would.
Nav document, NCX, landmarks and the visible contents page all generated from the same repaired heading hierarchy, so no two of them can ever disagree with each other.
Open every entry on a real device. Confirm the first thing on screen is the chapter title. Write down that you did it, and hand you the list.
Rated 4.9 out of 5 across 104 reviewed projects.
I had already paid someone else to format this book once. The chapter headings shifted every time a reader changed the font size and I only found out from a review. This team rebuilt the interior from the structure up and sent me photographs from four real devices before I uploaded anything. First launch day I have not spent refreshing the reviews in a panic.
What sold me was the audit. They came back and told me two chapters had been pasted in from another document and were carrying invisible styles, and that fixing that first would save me money later. Nobody had mentioned it in three years of self-publishing. The proof needed no corrections at all.
My book has footnotes, tables and two appendices, and every quote I got either ignored that or doubled the price because of it. Here the pricing was laid out step by step and I could see what each element cost before I committed. It arrived early and the notes link both ways, which nobody else had even offered.
The proof came back from the printer with the margins exactly where they should be, the running heads correct, and not one chapter opening on a left-hand page. This is my fourth book and the first time I have not had to pay for a second proof copy.
English is my second language and I was nervous about the back and forth. Everything was explained plainly, and when I asked the same question twice they answered as if it were the first time. The revisions were turned round inside two days and I was never made to feel like a nuisance.
I write cookbooks, so the interior is the product. Ingredients have to sit beside the method or the recipe stops working, and the last person I hired reflowed the whole thing into nonsense. These people understood the problem before I had finished describing it and the finished layout is genuinely beautiful.
Straightforward from beginning to end. A fixed price, a delivery window they actually hit, and files that went up to KDP and IngramSpark without a single rejection. I have since sent them two more titles and recommended them to my writing group without hesitation.
My memoir has photographs and I had resigned myself to them looking muddy. They optimised every image, told me honestly which two were too low-resolution to save, and suggested crops instead of shrugging. That candour is worth more to me than the discount I was chasing elsewhere.
I sent them a 480-page reference book with a nightmare of cross-references and a table on nearly every spread. They quoted it accurately, they did not come back later asking for more money, and the index still works. Any author will tell you what that is worth.
The questions authors actually ask us, answered without sales language.
It is the navigation layer of your eBook: the nav document a reading system parses, the NCX behind it for older hardware, the landmarks that decide where the book opens, and the contents page a reader can turn to. It is a separate service because it fails independently of everything else. Books with beautiful interiors ship with broken navigation every day, and the fix does not require touching a single line of your typography.
Because a contents page and a navigation file are different things, and having one does not mean you have the other. The page you can see is a styled list of paragraphs. The file a Kindle reads to build its Go To menu is a separate document most converters either skip or fill in badly. If your menu is empty on a device while the page looks fine in your preview, that is exactly the gap.
Almost always because the link points at the chapter file rather than at an id on the chapter heading itself. The reading system opens the file and begins rendering wherever it wants to, which on a small screen at a large font size can be half a page away from the title. We anchor every link to the heading element, then open every one of them to confirm where it actually lands.
The nav document is the EPUB 3 navigation file: an XHTML document with an ordered list carrying a toc role. The NCX is the EPUB 2 equivalent, an XML file with a navMap. EPUB 3 formally deprecated the NCX, but a large amount of Kindle hardware and older software still reads it first and ignores the nav document entirely. We build both, matched to each other, because the cost is negligible and the alternative is a reader with no contents list.
If you want your book to work on devices people bought before 2016 and have not replaced, yes. Deprecated means the specification would prefer you moved on. It does not mean the hardware in your reader's hand has moved on with it. The NCX adds a few kilobytes to the package and removes an entire class of complaint, which is an easy trade.
For a novel, one level. Chapters, in order, nothing beneath them. For business or self-help, two levels, because those readers skip to specific sections and the list is how they find them. For a textbook or reference work, three. Past three, the list becomes unusable on a phone. We will look at your structure and tell you honestly which one your book is, including when the answer is that it needs less than you were planning.
The copyright page, the dedication and the epigraph should not. They exist in the book and a reader will scroll through them, but listing them pushes chapter one down below the fold, and no reader has ever gone looking for a copyright notice. A foreword or an author's note usually should be listed, because those are pages people genuinely return to. We exclude by intent, never by deletion.
Because Amazon builds that menu from the navigation files in your package, and yours are missing or malformed. It is the most common failure we see and it is invisible in most preview tools, which is why authors discover it from a review rather than from a check. The fix is to build the nav document and NCX properly and confirm the menu populates in Kindle Previewer before the file goes anywhere near KDP.
Landmarks are a short second list in the nav document declaring where the cover is, where the contents page sits, and where the body of the book begins. The last one is the important one. It determines where a reader lands when they open your book for the first time. Without it, they can arrive at your copyright page, which is a poor first impression for a book someone has just paid for.
Yes, and it is the job we are asked for most often at this price point. A box set assembled by stitching finished files together usually keeps book one's navigation and loses everything after it. We merge the packages, build a master list with each book as its own level, and set landmarks so a reader can reach book four directly. Every entry is then opened, which on a five-book set is a long afternoon.
That is the problem, and it is the root of most of them. Visual styling carries no meaning to software. A tool building navigation looks for heading elements, finds none, and either produces nothing or guesses. Converting those styled paragraphs into a real heading hierarchy is the first thing we do, and everything else in the service depends on it being done first.
No. This service is navigation and nothing else, which is why it is priced the way it is. If we open your file and find genuine interior problems, we will tell you what they are in the structural note and leave them alone unless you ask us to quote for them. You should not be billed for work you did not want.
All of them. Every entry, on every navigation surface, on the devices in our test list. A ninety-chapter poetry collection means several hundred taps, and we do it, because a validator can confirm a link is well-formed and cannot confirm it goes anywhere useful. The verification sheet you receive lists what was opened.
Yes, as an add-on. In a reflowable eBook there are no page numbers, so an unlinked index is a column of words with no destination. We turn each entry into a live link that jumps into the relevant passage. It is meticulous work and it is the only thing that makes an index function in a digital edition rather than sit there as a fossil of the print one.
A page list maps the page breaks of a printed edition into the eBook, exposed in the navigation so that a device can report a real page number. Scholars citing your work need it. Library aggregators increasingly ask for it. If your book will never be cited or stocked by a library, you can skip it without losing anything.
Yes, and it is often the most valuable version of this job. Send us the file you uploaded, we repair the navigation, and you replace the file through your retailer dashboard. Existing buyers get the corrected version pushed to them on most stores, and the review that complained about the broken contents list stops being true.
They should, and we check it word for word. A list saying Chapter Nine while the page says The Long Way Down makes a reader think they have tapped the wrong thing. Where a title is genuinely too long for a phone screen we will discuss a shortened form with you rather than truncating it silently and hoping nobody notices.
It affects it considerably. A screen reader user navigates by structure, which means the heading hierarchy and the nav document are their primary way of moving through your book. Correct navigation is the foundation of an accessible file, though it is not the whole of it. If accessibility is your actual goal, our accessible EPUB service goes much further than this one does.
A standard novel is a two to four day turnaround, and the Rush tier compresses that considerably. The work itself is not slow. The link-by-link verification is what takes the time, and we do not shorten that at any speed tier, because a fast file with an unchecked link is the thing we exist to prevent.
On a short book it is the cheapest insurance you can buy. A twenty-thousand-word novella has perhaps twelve chapters, so the build is quick and the price reflects it. And a broken contents list on a novella is exactly as damaging to your rating as a broken one on an epic, because the reader leaving the review is not grading you on length.
Whether the navigation was never built, was built by a converter, or worked once and then stopped, we will look at the file, tell you what is actually wrong inside it, and quote a fixed price to make every entry land where it should.