Every office suite claims to open your files. The harder promise is sending them back unchanged where you changed nothing. Rixoffice builds its file handling around exactly that promise: a byte-preserving engine architecture that edits your existing documents instead of regenerating them, so the formatting, styles and parts Rixoffice does not touch survive every round-trip.
The problem with re-writing files
A modern Office file is not one blob — it is a package of parts: document XML, styles, themes, headers, charts, media, settings, metadata. Many editors take a shortcut: read the content, hold an internal model, and write a brand-new package on save. Anything the internal model did not understand gets dropped or flattened.
The symptoms are familiar: a template loses its theme, a watermark disappears, a chart becomes a picture, document properties reset, a file that opened cleanly in Word now triggers a repair prompt. Each one is a part the editor re-wrote badly.
How byte-preserving works
Rixoffice inverts the flow. Instead of rebuilding the package, its engines:
- Parse the existing OOXML package and keep every part in place.
- Patch only the pieces you actually edited — a paragraph here, a slide element there, a cell range somewhere else.
- Splice the patched pieces back into the original package.
- Save the file in place, with untouched parts byte-identical to how the original application wrote them.
The result: original formatting, styles and parts Rixoffice does not touch survive round-trips. Your company template keeps its theme. The legal watermark stays in the header. Charts, math, protection and metadata ride along untouched. And because AI edits happen at the block level, an AI-suggested rewrite patches the same way a manual edit does.
The three engines behind it
Rixoffice ships dedicated engines per format rather than one generic converter:
| Engine | Format | Approach |
|---|---|---|
| docx engine | .docx | Byte-preserving OOXML parse/patch/save with fragments, charts, math, protection, watermark and TIFF/metafile support |
| pptx engine | .pptx | Byte-fidelity parse/patch/save covering masters, layouts, placeholders, comments, SmartArt, animations, theme and custom geometry |
| Rust xlsx sidecar | .xlsx | Native compiled engine that parses and writes spreadsheets fast, without re-encoding parts it does not need to touch |
The docx and pptx engines are full OOXML implementations — they understand fragments, so a partial edit does not require a full-file rewrite, and they carry the format-specific features (math, charts, protection, watermarks, SmartArt, animations) as first-class parts. The Rust xlsx sidecar is a separate compiled process focused on speed for the format where file sizes get serious.
What survives a save
In practice, the parts that most often die in other editors are the parts Rixoffice keeps:
- Themes, masters and layouts in decks.
- Styles, headers, footers and footnotes in documents.
- Number formats, merged cells and untouched sheets in workbooks.
- Comments, revision marks and document properties everywhere.
- Charts, equations, SmartArt and media as native, still-editable parts.
What this means day to day
- Templates stay templates. Fill in a branded template in Rixoffice and hand it back; the branding survives.
- Round-trips are boring. Open in Word, edit in Rixoffice, open in Word again — nothing to fix in between.
- AI edits are safe edits. Block-level AI touches the blocks you approved, and the patching keeps the rest intact.
- Collaboration across apps works. Colleagues on Word, Excel and PowerPoint receive files that look like they never left.
Verify it yourself
You do not have to take the architecture on faith:
- Open a file that carries work you did not create — a company template, a partner's deck, a signed contract.
- Change one small thing: a date, a name, a number.
- Save with Ctrl+S, then reopen the file in the application that originally created it.
- Inspect what you did not touch — the theme, the headers, the charts, the page setup. It should be exactly as authored.
- Try the same with an AI edit; the block-level patch saves through the same engine.
Where the limits are
Byte-preserving applies to the native formats Rixoffice saves — .docx, .xlsx and .pptx — and to the parts those formats contain. Legacy .doc, .xls and .ppt files are read through compatibility filters and saved forward as modern formats, as described in the legacy formats guide. Exports to PDF and PNG are, by nature, new files rather than patches of existing ones.
What to explore next
- DOCX compatibility shows the Word engine in detail.
- XLSX spreadsheets covers the Rust sidecar and workbook round-trips.
- PPTX presentations explains element patching on decks.
- AI agents overview shows how AI edits flow through the same engines.