Blog › Build Story · Technical
A .docx file isn't one document.
It's several, wearing a trench coat.
Headers, footers and tables don't live where most rebrand scripts assume they do. Here's what's actually inside a Word file, and why that structure is the real engineering problem.
3+
separate XML parts in a typical document
550
templates walked consistently in one batch
11 min
to process every part of every file
1,000
pages handled in under 5 minutes
What a .docx file actually is under the hood (a zip of XML parts)
Rename any .docx file to .zip and open it. You'll find a folder structure of XML files: document.xml for the main body, separate files for headers and footers, a styles definition, a list of embedded media, and more. Word presents all of this as one seamless page on screen. Underneath, it's a collection of independent parts that happen to render together.
That distinction matters enormously the moment you try to change something programmatically. A script that edits document.xml and calls it done has touched exactly one part of a multi-part file - and usually not the parts causing the most visible problems.
Why headers and footers live separately from the main document body
Headers and footers aren't part of document.xml at all. They're their own XML parts, referenced by the section properties of the body, and a single document can have multiple header and footer parts - a different one for the first page, different odd and even versions, and a fresh set for every section break. A policy document with a title page, a table of contents, and three chapters can easily reference six or more separate header and footer parts, each needing the same brand update applied independently.
Why tables have their own formatting rules that ignore document-level styles
Tables carry table styles, which behave differently to paragraph and character styles. A table can have banded row shading, border colours and cell fills defined at the table-style level, then overridden again at the individual cell level by someone who manually reformatted one row years ago. Change the document's theme colour and a table's shading often doesn't move at all, because it was never wired to the theme in the first place.
Headers, footers and the main body are separate XML parts, and tables often carry their own direct formatting.
Direct formatting: the quiet reason "just change the theme colour" doesn't work
Word lets you apply formatting two ways: through a style, or directly to a run of text - bold this word, colour this heading, without touching the underlying style definition. Direct formatting always wins over style-level formatting. After years of edits by different people, most real documents are riddled with it. That's why "just update the theme" so rarely works as a rebrand strategy on its own: most of the colour and font choices on the page were never actually connected to the theme.
Style-level
Colours and fonts defined once, in theory inherited everywhere.
Direct formatting
Applied straight to text, overriding the style, invisible until you go looking.
Both, everywhere
A real rebrand has to catch both, in every part of the file, every time.
How BrandSwitch walks all of these consistently instead of missing them
The engine walks every XML part in a document: the main body, every referenced header and footer variant, and every table, checking both style-level definitions and direct formatting for colour, font and logo references. First page, odd and even headers, section breaks - all of it gets the same pass, applied deterministically, so nothing depends on which page you happen to check after the run.
What I'd tell someone building a similar tool from scratch
Don't start from the assumption that a document is one flat piece of text. Map out every part type first - body, headers, footers, tables, styles - and test against documents that have been edited by several different people over several years, not a clean file you created yourself for testing. The messy, inconsistent real-world document is the actual product requirement. A tidy demo file will lie to you about whether the tool works.
Quick answers
Why do headers and footers get missed by simple rebranding scripts?
A Word document stores headers, footers, and the main body as separate XML parts inside the file. A script that only touches the main body will run cleanly and still leave every header and footer in the old brand.
Why doesn't changing the theme colour fix a whole document?
Because direct formatting - colour and font settings applied straight to a run of text - overrides document-wide theme styles. Years of edits leave documents full of it, so a theme change alone often changes almost nothing visible.
Do tables need special handling in a rebrand?
Yes. Tables often carry their own formatting rules that ignore document-level styles, which is exactly why simple find-and-replace tools miss them even when the rest of the document updates correctly.
What does a rebrand tool need to handle to work properly on real documents?
It needs to walk every XML part in the file - headers, footers, the main body, and every table - and apply both style-level and direct formatting changes consistently across all of them, on every page including the fiddly first-page and section-break exceptions.
See it handle a real multi-section document
BrandSwitch was built to walk every part of a document, not just the parts a quick script would catch. Upload a document with section breaks, mixed header variants, and a few stubborn tables, and see the brand applied consistently across all of it.
See it handle the fiddly parts
Headers, footers, tables and direct formatting, all walked consistently.