Why your .docx looks different in another program
It is rarely a rendering bug. Most formatting loss happens at save time, when a program rebuilds a file it only partly understood — and that is a design decision, not an accident.
8 September 2026 · 7 min read
There are two different failures, and people conflate them
Rendering differences are what you see on screen. A font is missing and something is substituted; line breaking differs by a hair and a paragraph gains a line; a table is measured slightly differently and a column wraps. Annoying, visible immediately, and usually harmless — nothing in the file has changed.
Loss on save is the one that costs money. You open a document, change a word, save it, and something you never touched is now gone: a chart has become a picture, a content control has vanished, a signature is invalid, a macro project is missing, or a review comment thread has been flattened. You will not notice, because you were looking at the word you changed. The recipient notices, later.
The rest of this article is about the second one, because it is the one you can actually do something about.
What a .docx is made of
A .docx is a ZIP archive. Rename one to .zip and open it and you will find a small filesystem: `word/document.xml` holds the text and its formatting, `word/styles.xml` the style definitions, `word/media/` the images, `docProps/` the metadata, and `[Content_Types].xml` a manifest describing what each part is. An .xlsx and a .pptx are the same idea with different part names.
That structure is the reason both the problem and the solution exist. The parts are separable. A program can understand `document.xml` completely and have no idea what a particular extension part is for — and what it does about that is the whole story.
The rebuild problem
Most programs that open a .docx parse it into their own internal model — paragraphs, runs, tables, styles — and when you save, they write a brand-new .docx out of that model.
This is a completely reasonable design, and it has one consequence: anything the internal model has no representation for cannot be written back, because at the moment of saving it no longer exists anywhere. It was dropped during import, silently, and the save is merely where the loss becomes permanent.
And the list of things a young implementation has no representation for is long. Chart definitions with their cached data. Pivot caches. Custom XML parts that a document-management system put there. Content controls. Ink annotations. Embedded objects. Digital signatures — which are especially unforgiving, because a signature covers the bytes of the parts it signed, so re-serialising even the parts you did understand invalidates it.
The alternative: only rewrite what you edited
The other approach starts from the ZIP rather than from a model. Keep the original archive in memory. Parse the parts you need to display and edit. When the user changes something, modify only the parts that change actually touches, and write every other part back byte-for-byte, exactly as it arrived.
The difference is not incremental. Under a rebuild, everything you did not implement is lost. Under preservation, everything you did not *touch* survives — including formats invented after the software was written. Fidelity stops being a function of how complete the implementation is, and becomes a function of how much of the document the user actually edited.
It is harder to build, which is why fewer programs do it. Editing XML in place, keeping relationship IDs consistent, and not disturbing the ZIP entries you are passing through is more work than parsing into objects and serialising out. It is also the only approach under which a document can pass through software that does not fully understand it and come out unharmed.
What to do about it today
- Test with your own worst document, not a sample. Take the .docx with the charts, the tracked changes and the mail-merge fields, round-trip it, and diff the result — visually at least, or with a ZIP listing if you want to be thorough.
- Watch for the things that do not show on screen. Open the saved file and check that charts are still charts, that comments are still threaded, and that any signature still verifies.
- Prefer PDF for final delivery. If a document’s appearance is the deliverable and it will not be edited again, exporting to PDF removes the question entirely.
- Keep the original. As with everything in this genre, the round trip is only reversible if you kept what went in.
Our own product, disclosed
Where our own software comes into this
The preservation approach in the fourth section is the one our own engine takes, and describing it as the better design on a page we publish is obviously self-serving, so here is the check: open a .docx in Rutba Office, change one word, save it, and compare the ZIP entries against the original. Everything except the parts your edit touched should be byte-identical.
That is the claim, it is mechanically checkable, and it is why the engine exists — it was built for a document workspace that had to hand customers’ files back unharmed, and the free desktop suite is what it became.
It does not make us more capable than a mature suite. It makes the specific failure described in this article much less likely, which is a narrower thing to be good at.
Related
What is actually inside a .docx file
Rename it to .zip and look. Understanding the parts explains almost everything about why documents behave the way they do between programs — and lets you fix a corrupt file by hand.
Free alternatives to Microsoft Office, honestly compared
There are four serious ones and they are good at different things. The right answer depends almost entirely on who receives your files and whether you need to work offline.
Seven apps, one free download
No account, no telemetry, and it works with the network switched off.