WYSIWYG DOCX Editor for the Browser: True Document Fidelity vs Rich Text Editors
A WYSIWYG DOCX editor for the browser edits Word documents with full formatting visible as you type. The question is: does the editor work with native OOXML (the actual DOCX format), or does it convert DOCX to JSON or HTML for editing and convert back on save? Native OOXML editing preserves headers, footers, tracked changes, pagination, and complex tables. JSON-based editors lose some or all of these on the roundtrip. WYSIWYG stands for "what you see is what you get": the on-screen view matches the final output. Every editor in this comparison does this but the difference that decides whether a document survives a round trip to Word is what each editor stores underneath that view.
What Makes a DOCX Editor "WYSIWYG"
A DOCX editor earns the WYSIWYG label by rendering bold text as bold, tables as tables, and page breaks as page breaks, live, with no separate preview step. Apryse, OnlyOffice, Tiptap, SuperDoc, CKEditor, and TinyMCE all do this. On the surface, they look similar.
Opening a .docx file means parsing OOXML, the XML-based structure Word actually uses for headings, tables, headers, footers, and tracked changes, into whatever data model the editor runs on. Some editors keep that data model as OOXML from open to save. Others convert it into a different structure built for their own editing engine, then convert it back to OOXML when the user saves. That conversion step is where fidelity gets tested.
Native OOXML vs JSON-Based Editing
Apryse's DOCX Editor and OnlyOffice both edit the OOXML package directly. There's no intermediate document model and no conversion step between opening a file and saving it.
The editor reads the DOCX package (the XML parts, relationships, and embedded assets that make up a .docx file) and modifies that structure in place as the user types, formats text, or accepts a tracked change. Whatever the original file contained stays intact, because it was never translated into another format that would need to be translated back.
Tiptap, CKEditor, TinyMCE, and most rich text editor libraries convert an incoming DOCX file into their own document model, typically ProseMirror JSON or HTML, run the editing surface on that model, then convert the edited content back into OOXML on export.
This is a reasonable design choice for a rich text editor library. A flexible, framework-friendly document model built for arbitrary content and a small runtime footprint works well for a comment box, a CMS body field, or a chat message. It becomes a liability the moment a document has to reopen cleanly in Word.
What You Lose in the Roundtrip
Tiptap's own documentation lists specific DOCX elements its conversion pipeline does not carry through import by default: page breaks, headers and footers, horizontal rules, and certain text styles. An optional extension can re-render page-aware content, but without it, imported headers and footers have nowhere to render and page breaks are dropped.
CKEditor and TinyMCE both convert Word content into an HTML-based model for editing. Rich text editor libraries in this category treat comments, tracked changes, and header and footer XML as data that has to survive a JSON-or-HTML roundtrip, and that data commonly shifts or drops on the way back to DOCX.
Track changes present a specific technical hurdle. Word stores insertions and deletions as OOXML markup, w:ins and w:del elements, directly inside the document body. Only Apryse, OnlyOffice, and Collabora produce that markup in a form Word reads back correctly, and Apryse is the only one of the three that runs the entire editing session client-side.
Apryse's DOCX Editor exposes tracked changes programmatically through the TrackedChangeManager API, so a review workflow can accept, reject, or navigate to a specific change by ID from code, not just through the UI.
Architecture Comparison
The table below compares editing format and round-trip behavior across six DOCX editing options.
When Fidelity Matters
Fidelity matters the moment a document leaves the browser and reopens in Word. That's the line that decides which type of editor a workflow needs. If a file round-trips through DOCX, native OOXML editing isn't optional; if it never leaves the browser, a rich text editor works fine.
Legal review, financial compliance, and healthcare workflows fall squarely on the side that needs fidelity, because they routinely send a document back to Word after a browser-based edit. A contract redline in legal document review, a policy revision, or a discharge summary needs its comments, tracked changes, and formatting exactly where a reviewing attorney or auditor left them, something a JSON or HTML roundtrip can't guarantee.
A rich text editor library remains the right choice on the other side of that line: a CMS body field, an in-app comment thread, or any document that originates and stays inside the browser. Everywhere else, the fidelity question in this article applies directly. Whenever a file moves between the browser and Word, Google Docs, or another OOXML-based tool, native OOXML editing is what determines whether it survives.
How Apryse's DOCX Editor Works
DOCX Editor compiles Apryse's C++ core to WebAssembly and runs the entire editing session in the browser. The add-on reads and writes the OOXML package directly. There is no server call and no intermediate document model between the file a user opens and the file they save.
The constructor below opens directly into DOCX Editor mode. This example uses SDK v11+, which initializes via web component by default; v10.2 and earlier use the iframe pattern instead.
Before this runs, copy the static assets from node_modules/@pdftron/webviewer/public into a publicly served directory. See the static assets guide for framework-specific automation.
The editor inherits the WebViewer UI's WCAG 2.2 Level AA compliance, and every operation runs inside the same client-side security boundary as the rest of WebViewer: no document content reaches Apryse infrastructure.
