Subheadings in Table of Contents (Dissertation Formatting)

I’ve been writing a PhD dissertation in Scrivener for the past few years and am at the point where I’ve merged all my fragments together into single chapters, but I need all of my subheadings to show up in the Table of Contents, both for the final document but also just for purposes of working on the structure, navigating it, etc.

How can I create a Table of Contents with subheadings included, this is the standard format for theses and dissertations. I could just move to another program and finish it there, but I would rather keep working in Scrivener as I really enjoy it and didn’t want to have to do a final edit in other software until the final draft stage. Thank you for your advice!

I did search the forum and this question was asked in 2015 and the answer then was that it isn’t possible, so I’m wondering if the feature has been added since, or if anyone else has figured out how to do this. Thank you!

Each heading and subheading should be a Binder title. You may have merged more than you’ll find convenient.

Thank you, I do understand that would create the desired ToC but that structure won’t work. Making each subheading a separate document creates an extreme nested situation that I can’t work in or even process.

Is there no way to build a ToC using heading coding? That would seem to be a basic feature no?

It’s basic if you do it as designed.

Check out the 915 page Scrivener manual and its ToC. It was written in Scrivener, after all. You can download the manual as a Scrivener project, if you don’t believe it.

Does that mean the answer is no? Headings can’t be used to define a ToC?

Check out the 915 page Scrivener manual and its ToC. It was written in Scrivener, after all. You can download the manual as a Scrivener project, if you don’t believe it.

This is leaving out some significant information that I strongly doubt the OP is aware of. Most importantly to the discussion:

  • That Scrivener almost has nothing to do with the actual construction of the user manual as a PDF. That project makes use of the LaTeX typesetting engine to do almost everything mechanical that you see being done, including the construction of the ToC, and the much more detailed “mini-tocs” that appear after major chapter breaks, as well as its ability to create cross-references to any isolated piece of text, like figures in the middle of a block of text (something Scrivener cannot do by itself without spamming section breaks and hyperlink bookmarks everywhere, and necessitating chopping up the outline by content rather than by concept).
  • Although it is not employed frequently, and by and large the outline structure of that project does drive the heading hierarchy, I can and do insert heading markup in the content area itself. I am not limited by structure to produce a functional heading hierarchy that can appear in ToCs, and can seamlessly blend what is generated by the compiler with what I type into the editor. That is not a capability that is limited only to those using markup and LaTeX, however.
  • An implication in all of this (particulars of which software one uses in post aside) is that Scrivener isn’t the best place to be putting together the mechanics of a book. It is very limited for doing so, and unless one never needs to go beyond those limitations, there is no good solid reason for trying to constrain yourself to them. There are far better solutions outside of Scrivener, and arguably the compiler is designed to faciliate a seamless transition to them, moreso than it is attempting to replace them.

ToC Basics for Word Processing

If you already know how to make a ToC in a word processor, you can probably skim right past this and into the practical application stuff below.

So setting aside the technical details of how the manual differs from your average project with font styles and so forth driving appearance directly, there are a few key things to be aware of when it comes to generating a table of contents. These are by and large basic fundamentals for most (if not all) desktop publishing tools and word processors (which again, Scrivener is designed to aid seamless transition into):

  1. Functional structural headings are a combination of stylesheet application and the styles themselves declaring themselves as being part of the document outline.

    You don’t ordinarily need to mess with detailed settings, as most document designs will include a hierarchical heading structure in its stylesheet—typically indicated by “Heading 1”, “Heading 2”, “Heading 3” and so on. Scrivener is no different.

  2. A ToC is a construct that is inserted anywhere into the document which uses, as its data source for constructing itself, the overall use of hierarchical headings throughout the text.

  3. In more heavy-duty design environments all of the above is deeply customisable. In Scrivener you have to follow a simple convention, you must have styled headings using the naming scheme described above. It will look for this naming convention and build the outline settings into the stylesheet for you.

Thus in simple terms, to have a document we can add a functional ToC to, our only requirement is to have styled text throughout the document that is indicated as one of these “Heading n” type styles. Most ToC settings will indent the ToC entries based upon that hierarchy, and generate formatting for each line, including dotted lines connecting to the page number, or whatever else one wants.

So long as the final result is hierarchically coherent, it doesn’t matter where the styled text comes from. By coherent, I mean you don’t have Heading 4 following a Heading 2. The heading usage must correlate to logical depth, step by step.

Applied to Scrivener: given that basic requirement, and how all of this works, it does not matter how you get these headings into the output. They can come from the compile format’s Section Layouts, which are applied to outline structure in the Draft folder, and they can also come from styled text in the editor itself, or even exclusively, where the compile is doing extremely little and one is apply the “as-is” layout to everything.

Application of Styles in Scrivener

That is a bit of theory and background, so here are some practical tips:

  • Linking to Scrivener’s “no style” default to Word’s “normal” style.: this basic introduction mainly covers how to get “Normal” or “Body” styles applied to body text, but that is a good convention you should consider doing, and the principles here also apply to how you would apply “Heading 1” to a major section heading, and so forth.
  • compiling - sections, page breaks, styles: now this post goes more directly into applying stylesheet headings to a document for the primary purpose of generating a ToC, and includes a sample project wired up and ready to be finalised in a word processor.
  • How to add TOC to: just another checklist and sample document describing compile heading setup.

A Hybrid Approach of Compiler and Editor Headings

There aren’t as many existing discussions out there for blending that approach with headings in the editor as well, but that’s probably because it’s a fairly simple concept. Let’s say you have your major sections in the binder—perhaps chapter-level constructs, with “Heading 1” being applied to those headings by the compiler. Maybe you also break things down to level two, to the Section level, and have the compiler styling those smaller headings with “Heading 2”.

So given that framework, any headings you create in the editor, within those Section level documents will be “below” that level, or Heading 3, as Subsections. If there are headings in between those, in your text, they would be below that, using Heading 4, or what you’d think of as Subsubsections.

That leaves one final point: any headings you don’t want in the ToC should not use the “Heading n” naming convention. That’s it. Call it whatever you need (like “Subsubsection”).

One last thing pointing out is a feature in the Styles compile format design window:

  1. Open File ▸ Compile..., and double-click on the compile format you are using, in the left sidebar, to edit it.
  2. In the Styles pane, take note of the Override Name field. With this, you can take a style you’ve been using in the editor (like “Subsubsection”) and rename it on the fly to “Heading 4”.

Now consider the implications of that in terms of flexible project design. If your styles in the writing environment are pragmatically named, like “Chapter”, “Section” and “Subsection”, then by themselves they won’t actually be useful for generating a ToC. But, that doesn’t matter because we can use this Styles pane to rename them to “Heading 1”, “Heading 2” and so forth, as we require.

The implication is that we can drive the depth of the ToC purely from our compile settings. We don’t have a duct-tape and baling wire approach of changing styles names in the writing environment to suit the output requirements.

At this point in your project, that may be of lesser importance since you are nearing the end of using Scrivener. But it’s something to consider for the future. Styles, like almost everything in Scrivener, can be used in a writing-centric fashion, without having to conform oneself to the mechanical practicalities of output.


Thank you for this thorough reply and explanation. In my case I’ve used only the pre-existing Heading 1 and Heading 2. What surprised me was upon inserting a ToC it didn’t use those, instead it used the titles of the documents as they are in the binder. From a single read through of your answer it sounds like it should be possible to create a ToC in Scrivener using those headings instead of the binder document titles, or am I misunderstanding that?

I’ve created ToCs in Microsoft Word, for example, for my M.A. thesis, so I do understand how that works and how headings and styles work there. And I know that after I move the document there for final editing, that I can easily do what I want.

However, what I need now is a ToC that includes my Headings styles simply so I can see the structure of the writing more clearly while working in Scrivener, which is what led me to ask the question. Is that possible, or will the ToC generated in Scrivener always only be based on document names from the Binder?

1 Like

I’ve created ToCs in Microsoft Word, for example, for my M.A. thesis, so I do understand how that works and how headings and styles work there. And I know that after I move the document there for final editing, that I can easily do what I want.

Yes, that is what I am suggesting is the best solution for the final phases, which although in reading your response, I see might be a tangent from what you were looking to resolve here. I think in your case it is particularly so, given how you prefer a heavy dependence upon headings in the text rather than using Scrivener’s outlining-based approach, but in almost every case I would say a stylesheet-driven document, and a dynamic ToC inserted after compiling, will be better than how the Contents in Scrivener works.

We can really better think of that as a structured list of internal hyperlinks in static text. It doesn’t change if you rename or move things around—really it’s more meant to be the kind of thing you slap into the front matter somewhere directly before spooling off a proof copy, and anticipate having to rebuild frequently until the structure settles down. It’s more of a scaffolding system, something to make do with while in formative phases of the project.

However, what I need now is a ToC that includes my Headings styles simply so I can see the structure of the writing more clearly while working in Scrivener, which is what led me to ask the question. Is that possible, or will the ToC generated in Scrivener always only be based on document names from the Binder?

So yes, here is where we get to where I misunderstood you a bit. Since you were speaking of a table of contents, I figured you were looking to start the migration out of Scrivener (because that is the only time I would start thinking of such a tool, myself). However it sounds like you are looking for a navigation tool, more so? To the question: the binder names are all Scrivener has to work with, in most regards. The outline in the binder really is meant to be your “writer’s ToC”, through and through. If it doesn’t represent the structure you need to be able to work with the text effectively, then something is amiss.

Yes, we can weave additional headings into the text, as noted, but in my opinion that is a capability better reserved for non-Toc minor headings—things you don’t really need to know of until you’re already in the right place. For example, earlier you stated that having every subheading would produce too much structure to make sense of, and that is fair. There is the other side of the balance though, where if you remove too much structure the work becomes difficult to navigate in a program that isn’t designed around heading usage in the text much at all.

The best answer, it seems to me, is somewhere in between where you were and where you ended up. You’re now faced with a text that you cannot fully see. You’ve turned to the ToC feature as a way of trying to solve that (as one might in a word processor), but for the same reason things are now obscured to you, the ToC feature can no longer see that “deep” either into the structure of the text.

Hopefully these two considerations can be seen as independent, and in thinking of them that way, bring clarity into why it works this way:

  1. The draft folder should be as detailed as you need it, to work effectively. That tool is yours, and yours alone! It actually does not need to represent the structure of the document that it will eventually become. It can represent parts of it, maybe only broad strokes, or maybe for some people even more detail than the reader will ever see.
  2. By implication, the actual ToC that ends up in the final work can and should be entirely heading driven. It may be produced by a combination of compile inserted headings and stuff in the text editor you’ve styled, and where you start doing the latter is that line in the sand where draft outline structure ceases to be useful to you.

I mean to emphasise the second point only to clarify that talking about the structure useful to you need not be bound by what the ToC will eventually need.

1 Like

Thank you. Yes, for my process, I used nested folders of documents in the binder for several years of processing data and writing, but now found that in order to bring the writing to the next level of draft, to really have coherence, I needed to merge those into single documents, each of which is a chapter in the binder. Since I’ve done this I find that I’m able to work much more easily, write more easily, and all is going very well. The only piece missing for me is the ability to see the true structure of my document, which is based on headings. I do want to keep working in Scrivener for now, but it does seem I can’t see the structure of the document in the way I want as I do so, without moving backward in my process to breaking up these merged chapters into subsections again. Unfortunately due to the way I think and work that would not be good thing to do. Really the only thing missing here is an ability to see the actual ToC - for example a binder view that shows structure based on headings, would be extremely helpful. I will be continuing to work in Scrivener for many more months because other aspects of the folder structure are extremely useful as I work on integrating text, removing it, sorting out ideas and drafts - it’s just the actual body of the thing that I need to see slightly differently than the software allows.

A temporary solution, and the only one available at the moment, would seem to be compiling it, generating the ToC in the word processor, then copying that document back into my project so I can reference it. And running through that process as needed. I appreciate your explanations, they’ve all been very helpful and I’ve bookmarked all the links you included as well as I will need to refer to them. In the end, I think this turned into a feature request: To be able to generate a ToC based on headings.

To my mind being able to see the structure of your document in many different ways is helpful, and that’s one way of viewing it that is currently missing. But I never know if it’s my own thinking and learning differences that make these kinds of things useful for me, or something others might find helpful as well. Thank you again for all your discussion and help.

1 Like

How to convert Scrivener folder structure into main headings when I compile to Word, in order to see in navigation map?

Refer to the above post for a walk-through on setting up styled headings. This conversation mainly focused on doing this so that a ToC could be easily inserted in Word, but it is the same exact mechanism that populates the “Navigation” tool.

1 Like

What you are telling me is that if I use the table of contents of scrivener then when I pass it to Word ,I will see styles H1,h2 ?

Not quite, the “ToC” copy and paste thing in Scrivener is more of a quick proofing tool, it doesn’t really connect with anything or use conventions you’d want to use elsewhere after compiling.

What you want is for your section layouts, the middle column in the compiler, to have h1, h2 headings instead of merely formatted text. This section of the post has some links with more detailed instructions on setting that up right. The third link is probably the best, looking over them briefly.


How could you convert folder in Heading style, using TOC?

In the post I referred to there are instructions for setting up Section Layouts to use heading styles (again, the third link in the bullet list). So to use those for items in your binder, you need to Assign Section Layouts... in the main compile overview screen, bottom of the middle column. That is where you set up how the different types in your outline will look.

Could you describe at which step you are in need of more advice?

1 Like