Why does Word restart numbering when I merge documents?

Because each Word file contains its own private list of numbering definitions, and they're numbered from 1 in every document. When two files are combined, those definitions collide — and one document's lists get remapped onto the other's. The numbering isn't confused. It's following a different list than the one you think it's following.

The same collision, in different parts of the file, explains the vanished headers and the page numbers that suddenly run 1, 2, 3, 1, 2, 3.

This isn't a bug in Word, and switching tools won't avoid it. It's a consequence of how the .docx format stores documents, and once you can see the mechanism the fixes stop being guesswork.

A .docx file is a folder pretending to be a document

Take any Word file, make a copy, and rename the copy from report.docx to report.zip. Open it. It's an archive, and inside are the parts Word assembles into what you see on screen:

The critical detail is that last one. document.xml doesn't contain your images or reference your headers by name. It refers to them by relationship ID — rId4, rId7 — and the lookup table resolves each ID to a file.

Every document numbers its own relationships from scratch. So does every document's list definitions, and its style IDs. Two files that have never met each other both confidently use rId4 and numId 1 and Heading1, meaning entirely different things.

Key idea: Merging is the moment two documents' private naming schemes have to become one. Everything that breaks, breaks here.

Why the numbering restarts (or continues when it shouldn't)

Inside numbering.xml, a list is defined in two layers.

An abstract definition describes the look — decimal or bullet, indentation per level, whether the list restarts after a heading:

<w:abstractNum w:abstractNumId="0">
  <w:lvl w:ilvl="0">
    <w:numFmt w:val="decimal"/>
    <w:lvlText w:val="%1."/>
  </w:lvl>
</w:abstractNum>

A concrete instance points at it, and this is what paragraphs actually reference:

<w:num w:numId="1">
  <w:abstractNumId w:val="0"/>
</w:num>

And a numbered paragraph in your body text says, in effect, I belong to list 1:

<w:numPr>
  <w:ilvl w:val="0"/>
  <w:numId w:val="1"/>
</w:numPr>

Now merge two documents. In your first file, numId 1 is the numbered procedure in chapter two. In your second file, numId 1 is a completely unrelated bulleted checklist — because that file also started counting at 1.

Two things can happen, and both look like bugs:

The lists fuse. Both documents' paragraphs now reference the same numId, so Word treats them as one continuous list. Your second document's items pick up where the first left off — item 1 becomes item 9.

The lists get remapped. The merge renumbers one document's definitions to avoid the collision, but does it per-instance rather than per-abstract-definition. Sequences that should have continued now restart, because they've been split across two instances of the same underlying list.

This is also why the problem feels random. Whether you get fusion or restarting depends on which document was opened first, which tool did the merging, and how many lists each file happened to contain.

Why your headers and footers disappear

Headers and footers aren't attached to pages. They're attached to sections, and a section is defined by a <w:sectPr> element — section properties.

sectPr carries the page size and margins, whether the first page is different, and crucially the references to that section's header and footer files:

<w:sectPr>
  <w:headerReference w:type="default" r:id="rId7"/>
  <w:footerReference w:type="default" r:id="rId8"/>
  <w:pgSz w:w="12240" w:h="15840"/>
</w:sectPr>

Where that element sits matters. The final section's sectPr lives at the very end of the document body. Every earlier section tucks its sectPr inside the properties of the last paragraph of that section — an easy thing to miss, and an easy thing to drop.

When content from document B is appended to document A, B's body paragraphs come across but B's section properties frequently don't. With no section break carrying them, all of that content now falls inside A's final section — and inherits A's header and footer.

B's header hasn't been deleted. The file may still be sitting in the archive. Nothing points at it any more.

12240 x 15840 twips, by the way, is US Letter. A4 is 11906 x 16838. If you've ever merged a document from an international colleague and watched your page count jump, that's this same element.

Why page numbers restart in the middle

Page numbers are a PAGE field inside the footer, and whether they restart is controlled by one line in sectPr:

<w:pgNumType w:start="1"/>

Lose that element and continuous numbering runs through the whole document, including the front matter you wanted numbered separately. Gain one you didn't intend — because an inserted section break brought its own — and numbering restarts partway through.

It's the same root cause as the headers. Page numbering is a section property, and sections are what merging handles worst.

Why your headings change font

styles.xml defines styles by ID:

<w:style w:type="paragraph" w:styleId="Heading1">
  <w:rPr>
    <w:rFonts w:ascii="Calibri Light"/>
    <w:sz w:val="32"/>
    <w:color w:val="2F5496"/>
  </w:rPr>
</w:style>

Both your documents almost certainly define Heading1. One is 16pt Calibri Light in blue; the other is 14pt Times New Roman in black. After merging there is one styles.xml, so there is one definition of Heading1 — and every heading in one of your documents silently adopts the other's appearance.

This is also why Word's Keep Source Formatting paste option can't fully rescue you. It works by applying direct formatting on top of the style, which is why a document pasted that way becomes almost impossible to restyle later: the formatting is no longer coming from the style at all. You've traded a visual problem for a structural one.

What actually survives a merge

A useful rule: anything stored inline survives, anything stored by reference is at risk. That single distinction predicts almost every merge failure you'll hit.

How to merge without the breakage

Ordered by how much trouble each step saves you.

1. Standardize styles before you combine anything. If all your source documents were created from the same template, Heading1 means the same thing in each of them and the collision is harmless. This is the single highest-leverage fix, and the only one that has to happen before the documents are written. If you regularly assemble reports from other people's files, send them a .dotx template instead of asking them to match your formatting by eye.

2. Insert a real section break, not a page break. In Word for Microsoft 365 on Windows: Layout → Breaks → Next Page under Section Breaks. On Mac: the Layout tab, same place. A page break just pushes text down. A section break creates a new sectPr, which is what gives the incoming content somewhere to keep its own headers and page setup.

3. Unlink the headers. New sections inherit the previous section's header by default. Double-click into the header, and in the Header & Footer tab turn off Link to Previous. Do it for the footer separately — they're independent.

4. Fix numbering deliberately rather than hoping. Right-click the first item of a list that's behaving wrongly and choose Restart at 1 or Continue from Previous List. You're telling Word which numId that paragraph belongs to. Guessing by deleting and retyping the number gives you a hardcoded character that will not renumber when the document changes.

5. Set page numbering per section. Insert → Page Number → Format Page Numbers, then either Continue from previous section or Start at.

6. Check your work with Reveal Formatting. Shift+F1 on Windows opens a pane showing exactly which style and direct formatting apply to the selection. It's the fastest way to find out whether a heading that looks wrong is genuinely styled wrong or just displaying an inherited definition.

7. Be cautious with Master Documents. Word's Master Document feature is designed for exactly this job, but it has a long reputation for being fragile with large documents. If you use it, keep separate backups of every subdocument.

What to check after any merge

Scroll the whole document once, deliberately, looking for four things:

• Numbered lists that restart or continue unexpectedly
• Headers and footers that change or vanish at a section boundary
• Page numbers in the footer that don't run the way you intended
• Headings whose font changes partway through

Doing this takes two minutes and catches almost everything. The alternative is discovering it after you've sent the file.

FAQ

Try ConvertSnap.in free — no sign-up, no upload →