eigenpal/docx-editor: A React and Vue .docx Editor That Keeps Unsupported OOXML

The round-trip problem docx-editor is built around

Most browser-based document editors make the same quiet promise: open a .docx, let the user change something, save it back. The failure shows up later, when a reviewer opens the saved file in Word and finds that a field, a content control, a chart or some vendor-specific XML has been flattened or dropped. The document still opens, so nobody notices until it matters.

docx-editor states the opposite goal in its README: "lossless round-trip: untouched content and unsupported OOXML survive the save." That is a narrower and harder target than general document editing. It means the editor has to parse OOXML it does not render, hold it in the model, and write it back out. For teams building contract review, document generation or a Word-compatible editor inside an existing product, that behaviour is the whole reason to pick a library rather than a hosted editor.

The audience is therefore developers, not end users. The packages are React components, Vue 3 components and a core parsing and rendering engine. If you want a free online Word editor to open a file on your laptop, this repository is not that product, even though the live demo at docx-editor.dev/editor shows what the library renders.

How the packages split: core, adapters, and the pro licence

The monorepo publishes several npm packages. @docx-editor.dev/core handles DOCX parsing, editing and rendering. @docx-editor.dev/react and @docx-editor.dev/vue are the framework adapters. @docx-editor.dev/i18n holds translations and locale types, @docx-editor.dev/fonts provides open-licensed substitutes for Word fonts, and @docx-editor.dev/docx-to-markdown exports to Markdown with page and image output.

The licence split is the part that decides whether this fits your project. The repository's badge reads Apache 2.0 + Pro. Two packages, @docx-editor.dev/editor-api and @docx-editor.dev/pro, are licensed under the EigenPal Pro License, with separate LICENSE.md files in packages/editor-api and packages/pro. The pro package is where the README places tracked changes, comments, collaboration and custom nodes. The pricing page is the place the README points to for comparing and buying licence and support levels.

So the tracked-changes feature set that the project description advertises is not in the Apache-2.0 core. That is a normal commercial arrangement, but it changes the evaluation: you are assessing an open-source engine plus a paid feature layer, not a single permissively licensed editor.

One practical note in the README for anyone extending the library: if you fork an adapter, depend on @docx-editor.dev/core so you receive engine fixes. Forking the React or Vue wrapper and pinning an old core cuts you off from parsing and rendering changes.

Installing docx-editor and rendering a first document

The README gives npm install commands for both frameworks. React pulls in the React adapter plus core; Vue pulls in the Vue adapter plus core. The packages target Node.js ^20.16.0 || >=22.3.0 for server-side use, and browser applications can consume them with their own build tool.

npm install @docx-editor.dev/react @docx-editor.dev/core   # React
npm install @docx-editor.dev/vue @docx-editor.dev/core     # Vue

The React quick start is a file input feeding a Uint8Array into the DocxEditor component, with the core stylesheet imported alongside. The document prop takes the bytes and mode is set to "edit".

import { useState } from 'react';
import { DocxEditor } from '@docx-editor.dev/react';
import '@docx-editor.dev/core/styles/editor.css';

export function App() {
  const [doc, setDoc] = useState<Uint8Array>();
  return <DocxEditor document={doc} mode="edit" />;
}

The Vue example is the same shape with a ref and a change handler, importing @docx-editor.dev/vue and its stylesheet. Both READMEs carry the same constraint in a note: the editor requires the DOM. Next.js and other SSR setups must use dynamic import, and Nuxt should load the editor in a client-only component. If your page renders on the server, plan for that boundary before you write the integration, because it affects where state lives.

After the editor mounts, the README's font guidance is the next thing to handle. Passing usable font bytes gives Word-accurate line and page breaks; without them the editor falls back to measurement that, in the README's words, "does not guarantee Word-compatible layout." Two entry points are named: packagedFonts() from @docx-editor.dev/fonts for packaged substitutes, and customFonts() from @docx-editor.dev/core/editor for your own font files.

Pagination fidelity depends on fonts you have to supply

The font requirement deserves its own section because it is easy to miss and hard to fix later. Word decides where a page breaks using the metrics of the fonts named in the document. A browser has those fonts only if the user's machine happens to have them, which for Word's default fonts it usually does not.

The library's answer is to let you supply font bytes and measure against them. @docx-editor.dev/fonts ships open-licensed substitutes for Word fonts, which is the pragmatic route; customFonts() from @docx-editor.dev/core/editor is the route for shipping your own licensed font files. Either way, the accuracy of pagination is a function of what you provide, not something the library can guarantee on its own.

That has two consequences worth stating plainly. First, page count in the editor can differ from page count in Word if the substitutes differ metrically from the originals, and the README does not claim otherwise. Second, font licensing becomes your problem: the README describes the fonts package as open-licensed substitutes, and anything you pass through customFonts() you have to be entitled to distribute. For a document editor embedded in a commercial product, that is a procurement question, not a technical one.

Where docx-editor is the wrong choice

The clearest mismatch is the one the search results keep surfacing: people looking for a free online Word editor or a desktop .docx editor. docx-editor is a library you install into an application you are building. There is no Windows or macOS application to download, and the demo site is a demonstration of the engine rather than a hosted service you can hand to a colleague.

The second mismatch is feature scope against licence. Tracked changes, comments and collaboration are named in the project description and in the README's package table, but the table places them in @docx-editor.dev/pro, which the README says is licensed under the EigenPal Pro License. A team that reads only the headline and plans a review workflow on the Apache-2.0 core will discover the gap during integration. Check the pro package's LICENSE.md before you scope the work.

The third is architectural. Because the editor requires the DOM, any server-rendered route needs a client-only boundary. If your product's editing surface is a server component that streams HTML, you are restructuring that route, not adding a dependency to it. The README documents the workaround (dynamic import for Next.js, a client-only component for Nuxt) but the restructuring is still yours to do.

Finally, the README does not document a rollback path or a migration story between major versions. The docs are versioned under /docs/2.x/, which tells you the current line, but nothing in the repository describes what happens to documents saved by an older release. Treat that as unverified and test it yourself with your own files.

docx-editor against a headless conversion tool

The obvious alternative for server-side work is a headless converter rather than an editor: something that takes a .docx and produces Markdown, HTML or plain text without a browser. That is a different shape of tool with a different cost model. It runs in a Node process, needs no DOM, and produces output rather than an editing surface.

Interestingly, this repository ships one of those too. @docx-editor.dev/docx-to-markdown converts DOCX to Markdown with page and image output, and there is a python/docx-to-markdown workspace in the monorepo alongside an examples/docx-to-markdown example. So the honest comparison is not docx-editor versus a converter; it is which half of this repository you need.

If your goal is to extract text and structure from uploaded documents, the Markdown package is the smaller dependency and avoids the DOM entirely. If your goal is to let a person edit the document in a browser and save it back with fidelity, you need the editor packages and the font work that comes with them. Choosing the editor when you only needed conversion means carrying a rendering engine, a stylesheet and a font pipeline for no benefit.

Maintenance, releases and what the licence split costs you

The repository is not archived. The last push was on 2026-09-17, and the recent release list shows @docx-editor.dev/react@2.20.0 and @docx-editor.dev/vue@2.20.0 both published on 2026-09-16, with a 2.19.1 Vue release earlier the same day. The React and Vue adapters are versioned in step, which simplifies dependency alignment: pinning both to 2.20.0 is possible.

On upgrade cost, the monorepo uses changesets (.changeset/ is a top-level directory) and the docs are versioned by major line under /docs/2.x/. The README's advice to depend on @docx-editor.dev/core when forking an adapter is the practical upgrade rule: keep the engine on the published version and your own wrapper thin. The README does not describe a deprecation policy or a support window for older 2.x releases, so if you need that commitment, the pricing page and the pro licence terms are where to look rather than the README.

On licensing, the split matters more than the version numbers. The core, React, Vue, i18n, fonts and docx-to-markdown packages are covered by the repository's Apache 2.0 badge. @docx-editor.dev/editor-api and @docx-editor.dev/pro are under the EigenPal Pro License with their own LICENSE.md files. The repository's LICENSE file is the authoritative text for the open-source portion; the two package-level files govern the rest. Read both before you decide which packages your product depends on, and treat the pricing page as the source for what a commercial licence includes. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt docx-editor if you are embedding .docx editing inside a React or Vue application and need the file to survive a round trip with content the editor does not understand. Do not adopt it if you need a hosted Word editor for end users with no build step, or if tracked changes, comments and collaboration are required on day one, because those live in @docx-editor.dev/pro under the EigenPal Pro License rather than the Apache-2.0 core. Before committing, verify three things against the repository: the exact licence text in packages/pro/LICENSE.md and packages/editor-api/LICENSE.md, whether the font bytes you can legally ship produce Word-compatible pagination through customFonts(), and whether the client-only requirement fits your framework's rendering model.

Frequently asked questions

Official sources

1. eigenpal/docx-editor on GitHub
2. Issues
3. Project website
4. README
5. Releases