A header or footer nothing paints

docx.unrendered-header

Text sits in a header or footer part whose every reference is switched off, or which nothing references at all.

How the text is hidden

<w:headerReference w:type="first"> paints only when the section also carries <w:titlePg/>; w:type="even" only when settings.xml carries <w:evenAndOddHeaders/>. Word writes both the reference and the part when "Different First Page" is ticked and leaves them behind when it is unticked. A second population is stronger still: a word/headerN.xml or footerN.xml part that the reference graph never mentions.

Why a model still reads it

Parts are enumerated from the package, not from the reference graph, so python-docx and unstructured return the text like any other header. Nothing paints it.

What we do about it

The parser builds disabled and painted sets from every w:sectPr in document.xml plus the relationship map, removes from the disabled set any part that is also painted somewhere, and adds parts present in the archive that no reference names. An unpainted part whose flattened text a painted part already contains is suppressed — whole-string containment, not word overlap. The run must also contain a non-digit character. The reason is unrendered-reference; the rule fires at medium, action flag, and containerVisibility reports editing-only, because one checkbox in the Layout ribbon paints it.

How often it fires

8% of real commercial legal DOCX — 1,586 English contracts and agreements (corpus-legaldocx), mixed A4 and Letter, measured 2026-08-29.

This is an alert-volume number and nothing else. It says how often the alarm sounds on documents as found — not how often it is right, and not whether what it found was harmless. Documents as found may themselves carry concealment. Read it against the population named above rather than as a property of documents in general.

next

Check your own file

Three commands: a key, credit, a verdict.

Start with the API