LaTeX \include vs \input: Structuring a Multi-File Document So Partial Builds Still Resolve References

On a long LaTeX document, the expensive part of the edit-compile cycle is usually rebuilding chapters you did not touch. The kernel offers one mechanism for skipping that work — \includeonly — but it only works on files pulled in with \include, not \input. Choosing between the two commands is therefore a build-workflow decision, not just a file-organization preference.

The short answer: use \include for top-level chapters or sections that should start on a new page, and \input for everything else — preamble fragments, front matter, and any file nested inside an included one. Then \includeonly becomes available when you need it.

The two commands do different things

\input{file} is a plain textual insertion: LaTeX reads the file as if its contents were typed at that point. No page break, no extra auxiliary file.

\include{file} does more. It issues \clearpage before and after the insertion, so the included file always begins on a fresh page, and it writes a separate .aux file for that unit. An .aux file is the per-run scratch record where LaTeX stores labels, page numbers and counter values; the main .aux pulls in the sub-files. That separation is what makes selective compilation possible.

Two constraints follow directly. First, \include cannot be nested inside another \include — the kernel rejects it. Second, the forced page breaks are not optional.

Comparison

Behavior	\include	\input
Page breaks	\clearpage before and after	None; inserted inline
Auxiliary file	One .aux per included file	None
Nesting	Cannot be nested inside another \include	Can appear anywhere, including inside an included file
Honors \includeonly	Yes	No
Typical use	Top-level chapters or sections that should start on a new page	Preamble fragments, front matter, nested files, content that must not force a page break

What \includeonly actually buys you

Placed in the preamble, \includeonly{chapters/methods} tells LaTeX to skip every \included file except the ones listed — but it still reads the existing .aux files of the skipped units. Labels, cross-references and page numbers from the last complete run therefore remain usable. You get a shorter compile without a cascade of undefined-reference warnings.

The dependency is the catch: \includeonly is only as good as the .aux data already on disk. Delete the auxiliary files, switch branches, or add a chapter that has never been built, and references to the unbuilt material will not resolve until you run a full build.

Trade-offs

• Cost of \include: extra .aux files to manage, unavoidable page breaks, and a slightly larger set of generated files to keep out of version control.
• Benefit: per-file auxiliary data, which is the prerequisite for \includeonly partial builds.
• Cost of \input: no selective compilation. Skipping an \input file means commenting it out, wrapping it in a conditional, or adopting a package such as subfiles, import or standalone — each with its own rules and constraints.
• Benefit: no forced page breaks, no nesting restriction, and simpler file bookkeeping.

Do not assume a specific speedup. The gain depends on document size, engine and machine, and should be measured on your own project rather than taken from someone else's numbers.

A layout that supports both modes

% main.tex
\documentclass{book}
\includeonly{chapters/methods}   % preamble only; comment out for full builds
\begin{document}
\frontmatter
\input{front/titlepage}
\tableofcontents
\mainmatter
\include{chapters/intro}
\include{chapters/methods}
\include{chapters/results}
\appendix
\include{appendices/raw-data}
\end{document}

Note the split: front matter and the title page go through \input because they must not force page breaks, while each chapter goes through \include so it can be selected individually. The argument to \include and \includeonly is a path without the .tex extension, and the strings must match exactly — a mismatch silently skips the file you meant to build. Path handling can differ between engines and working directories, so keep paths relative to the main file.

Validating the setup locally

1. Build the document completely, twice, so references settle. Confirm that one .aux file exists per \included unit alongside the main .aux.
2. Record a baseline: the PDF page count and a handful of \ref values from the full build.
3. Uncomment \includeonly and rebuild without a full run. Check the .log for No file <name>.aux warnings — those indicate \includeonly is running without prior auxiliary data for that unit.
4. Compare the partial build's page count and the sampled reference values against the baseline. References to skipped chapters should still resolve; if they do not, the auxiliary data is missing or stale.
5. To confirm the nesting rule, try an \include inside an included file, observe the kernel error, and replace it with \input.

Failure modes worth knowing

• Stale or missing .aux files: the most common cause of wrong page numbers or unresolved references under \includeonly. The fix is a full build, not a tweak to the selection list.
• New chapter not yet built: it has no .aux file, so anything referencing it will not resolve until a complete run.
• Expecting \includeonly to skip \input files: it will not. Those files are always read.
• Wrapper packages and build tools: subfiles, import and standalone change these trade-offs, and tools such as latexmk may make their own decisions about rerun counts. Verify behavior against the TeX distribution actually installed rather than assuming a default.

Reverting and releasing

Removing or commenting out the \includeonly line restores the full build; nothing else in the source changes. The generated .aux files can be deleted safely, though deleting them costs you the partial-build capability until the next complete run. Before releasing or submitting a document, always run a full build without \includeonly — a partial build is a working convenience, not a deliverable.