Perfect Word roundtripping isn't us

Perfect Word roundtripping isn’t us

If you expect perfect Word roundtrips, you’re going to be disappointed. This isn’t what we do, and it’s not something we’re ever going to actively pursue. We do strive to make our documents as close as possible to their Word counterparts and will keep working towards that goal, but claiming we offer perfect roundtripping would be an outright lie.

What perfect roundtripping actually means

Perfect roundtripping is the guarantee that a document comes out of the editor exactly as it came in. It doesn’t mean every feature is available. Editors that focus on fidelity, like SuperDoc  and docx-editor.dev , understand part of the document and preserve the rest as-is, so a file survives a save even if you can’t view or edit everything inside it. That’s a perfect fit for someone whose main use case is: get a DOCX in, let the user tweak it, get the DOCX out.

Which features fall into the “preserved but not editable” bucket changes from release to release, so check their current feature lists against what you need: advanced legal numbering, styles, cross-references, multi-column layouts, or sections with different page sizes and margins.

Why we went the other way

There were really two choices here:

1. Offer perfect roundtripping, bend to 40+ years of Word legacy, and compete with well-funded teams already deep into it.
2. Start fresh, and simplify the API and data model.

We chose the latter, for the very simple reason that DOCX roundtripping has never been something we needed. We started building this editor for document automation workflows, meaning the document is created entirely by the editor or a server. Only then does the user download the DOCX, if needed. That’s the part that matters to us: a high-fidelity DOCX output. But nowhere in this flow does the user upload a DOCX to the editor and download it again. To put it simply, this isn’t an “edit your DOCX online” sort of product.

Then look at the complexity of OOXML, the 5000+ pages of ECMA-376, and this comical post on r/ProgrammerHumor, aptly titled wouldNotWishThisHellOnAnyone , and you get the idea. On top of that, roundtripping means your data model has to either mirror the DOCX spec or carry the original XML around alongside it, even for the parts the editor never uses. That adds clutter to the model, makes documents larger for a benefit we’re not chasing, and adds a layer of complexity for agents generating or manipulating content.

Owning our model instead gets us:

• A schema we control. We can evolve it freely, without OOXML’s quirks dictating the shape of every node.
• Smaller documents and smaller changes. Cheaper to store and sync, faster to load, and simpler to diff and track changes on.
• One model, many outputs. The same document exports to DOCX, PDF and Markdown, without everything being DOCX-shaped.
• Fewer invalid states. A tighter schema is easier to validate and sanitize than opaque XML passed through untouched. Where we do keep some XML (a few DrawingML picture effects we don’t model yet), it’s narrow fragments on the picture node, sanitized on import, never the whole package.
• Simpler server-side generation. Templating and automation work on a model built for it, which is exactly our use case.

There’s also a more fundamental reason: our schema is meant to be extended. You can add your own nodes, and the moment you do, there’s often nothing in DOCX that matches them, so perfect roundtripping is moot anyway. Sure, you could wrap them in content controls and stash the data there, so it survives the trip. But in Word, that’s just a generic box around some plain content. The node’s rendering and behaviour don’t come along, so it’s half a solution at best.

Presumably for the same reason, fidelity-first editors are more constrained here. At the time of writing, docx-editor.dev offers custom nodes stored as content controls, and SuperDoc lets you attach custom data backed by content controls and custom XML parts. Both are sensible choices when DOCX is the source of truth, but they bound what you can build to what DOCX can hold.

Who should use what

If your use case is like ours, and you’re not building a “DOCX editor on the web” but a tool to create, edit and manipulate documents without worrying about roundtripping, we’re the right fit for you. If not, take a look at SuperDoc  or docx-editor.dev . Both put DOCX fidelity first and seem to have gone very deep down the rabbit hole.

The claims about other products in this post are based on publicly available information and are, to the best of our knowledge, accurate as of October 2026. If anything here is inaccurate or out of date, we’d genuinely like to fix it. Email us at info@innovars.eu.