DOM-docx review 2026. Honest scoring on conversion fidelity, feature coverage, dependency footprint, maturity, license — and who floodtide's HTML-to-.docx library is for.
DOM-docx is a clean, well-scoped open-source library that does one thing well: convert semantic HTML into native, editable Word (.docx) documents — real paragraphs, lists, tables, and images, not a screenshot. Judged as what it is, a developer conversion tool, it is genuinely useful, with a light dependency core, three delivery modes, and solid document controls. It is also early — a v0.1.x release with documented limits — and, by design, it generates no content and publishes nothing. Reach for it when you need the Word file; look elsewhere when you need the content made.
Most quick takes on DOM-docx will call it "an HTML-to-Word tool," which is accurate but hides the important part: DOM-docx is a developer library, not an app you open and click around in. It converts semantic HTML fragments into native, editable Word documents in the OOXML (.docx) format — and it does that job with more structural fidelity than the usual screenshot-or-layout-hack approaches, emitting real paragraphs, runs, lists, tables, and images that a person can keep editing in Word.
What makes it worth a serious look is the engineering discipline. Published by floodtide on GitHub under the MIT license, it keeps a light dependency core — docx, cheerio, and fflate — needs no browser on its default path, and ships three ways: a CLI, a Node API, and an in-browser bundle. Its authors describe building it against a visual-regression loop (render HTML, convert, rasterize, score fidelity, iterate), which is a more rigorous quality bar than most small converters bother with.
This review scores DOM-docx as a document-conversion library, the only fair frame. I will not mark it down for not writing copy or scheduling posts, because it never claimed to — it is a converter. But I will be clear about the boundary, since "turns HTML into documents" can read, to a non-developer, like a finished content tool, and it is not one. Every claim here is grounded in the public GitHub repo as of the authoring date; it is an early project, so treat specifics as a fast-moving snapshot.
DOM-docx is an open-source library for converting HTML fragments into native Word documents. Its main function, `convertHtmlToDocx(html, options?)`, resolves to a Buffer on Node (a Blob in the browser bundle), and a CLI wraps the same engine (`npx dom-docx input.html -o output.docx`, with stdin/stdout piping for pipelines). On the input side it handles headings, paragraphs, ordered and unordered lists, tables, links, inline formatting, blockquotes, horizontal rules, simple flex rows, block backgrounds, page breaks, `data:` images, and remote images via an `imageResolver`. On the document side it can configure page size, orientation, margins, a default font, metadata, header and footer HTML, page numbers, a table of contents, language and direction, and a cover page. It runs on Node.js 20 or newer with a deliberately small core (docx, cheerio, fflate). Playwright and Chromium are optional, needed only for a "computed" style mode — which resolves `<style>` blocks and CSS classes through `getComputedStyle` — or for rasterizing `<canvas>` and complex SVG to PNG. It is a v0.1.x release with explicit limits: no external stylesheets on the inline path, no web fonts, no CSS grid or float layout, no forms, and no table `rowspan`. It generates no content and publishes nothing; its job begins after the HTML exists and ends when the .docx is written.
The clear fit is a developer who needs to turn HTML into editable Word files — inside a reporting feature, a document-export button, a CMS, or a build pipeline — and wants a focused, open, self-hostable tool rather than a heavyweight service. Teams that generate HTML content and need a clean .docx deliverable (proposals, reports, lead magnets) are the natural audience, as are engineers who value the MIT license and the light footprint. It is a poor fit for anyone who is not a developer, since it is a library, not an app, and it is the wrong tool entirely for someone whose real goal is producing and distributing content — there is nothing in it for generation or publishing.
| Dimension | Score | Why |
|---|---|---|
| Conversion fidelity (HTML → editable Word) | 4.3 / 5 | Emits real Word constructs — paragraphs, lists, tables, images — not a screenshot, and is tested against a visual-regression loop. |
| Feature coverage (input HTML) | 4.0 / 5 | Handles headings, lists, tables, links, blockquotes, images, and simple layouts; complex CSS and graphics have documented gaps. |
| Document controls (page setup, headers, TOC) | 4.2 / 5 | Page size, margins, fonts, metadata, headers/footers, page numbers, table of contents, and cover pages are all configurable. |
| Developer experience (CLI, Node, browser) | 4.3 / 5 | Three delivery modes and a simple API; stdin/stdout piping suits build pipelines well. |
| Dependency footprint | 4.5 / 5 | Light core (docx, cheerio, fflate) with no browser needed by default; Playwright is optional and lazy-loaded. |
| License & openness (MIT) | 4.5 / 5 | Free, MIT-licensed, and self-hostable, with no lock-in on the conversion step. |
| Maturity & stability | 2.5 / 5 | A v0.1.x release with several documented limits; capable but young, and moving quickly. |
| Content production & publishing | 1.0 / 5 | Out of scope by design — no generation, no images or video beyond conversion, no scheduler, no publishing. |
DOM-docx is free and open source under the MIT license, so there is no price tag on the library — and for a converter with this level of fidelity and testing discipline, that is a genuinely good deal for developers. The funding model is the standard open-source one; there is no hosted tier, no seats, and no per-document metering.
The honest cost is engineering, not money. Adopting DOM-docx means wiring it into a product or pipeline and maintaining that integration, and at v0.1.x it also means absorbing some risk of a moving target — documented limits around CSS, and the optional Playwright dependency if you need computed styles or complex graphics rasterized. For a team that wants an open, self-hostable Word-export step and is comfortable tracking an early project, that trade is fair.
The framing to keep straight: this is infrastructure pricing, not product pricing. There is no content output to pay for, because DOM-docx is a building block. If you were weighing it against a paid HTML-to-Word API, the library can be far cheaper at scale — provided you have the engineering to run it and can live with its current gaps.
| Use case | Fit | Why |
|---|---|---|
| Turning HTML content into an editable Word file | Strong | This is DOM-docx's entire purpose, and it does it with real Word constructs, not a screenshot. |
| Adding a document-export feature to a product | Strong | The Node API and browser bundle drop cleanly into an app that already has HTML to export. |
| Batch conversion in a build pipeline | Strong | CLI with stdin/stdout piping makes automated, headless conversion straightforward. |
| Complex-CSS or grid/float layouts | OK | The inline path has documented limits; computed styles need the optional Playwright dependency and still may not cover every case. |
| A non-developer who just wants a Word doc | Weak | It is a library, not an app; there is no interface to open without integrating it first. |
| Generating the content itself | Weak | DOM-docx converts existing HTML; it writes nothing. |
| Publishing content to social platforms | Weak | No generation or distribution at all — it is a converter, not a content maker. |
DOM-docx and Kompozy are not rivals, and scoring one against the other would be a category error — which is why the content-production dimension above is noted as out of scope. DOM-docx is a converter: HTML in, an editable Word document out. Kompozy is a content generation and publishing engine. The two even complement each other in sequence — and Kompozy deliberately does not export .docx files, so if a Word document is the deliverable you need, DOM-docx (or another converter) is the right tool and genuinely wins there.
Where Kompozy lives is the step before the converter. It fans one source into 18 output formats — persona and avatar video, clipped shorts, carousels, quote graphics, infographics, blogs, newsletters, and platform-native text posts — all held to one brand voice through a Persona Brief, then schedules and publishes the whole set across nine platforms plus email and blog from a single queue, on managed Claude and OpenAI models so there is nothing to build or run. A practical pairing: Kompozy writes the blog article or newsletter, and DOM-docx converts that HTML into a downloadable Word lead magnet, while Kompozy publishes the same message everywhere else. If your job is exporting documents, use DOM-docx. If your job is producing and distributing a week of on-brand content, that is the specific gap Kompozy fills — and no converter, however clean, closes it.
DOM-docx is an open-source (MIT) TypeScript library from floodtide that converts semantic HTML fragments into native, editable Word documents in the .docx (OOXML) format. It emits real paragraphs, lists, tables, and images rather than a screenshot, and ships as a CLI, a Node API, and an in-browser bundle.
For a developer who needs to turn HTML into editable Word files, yes — it is a focused, well-tested, MIT-licensed converter with a light footprint and three delivery modes. If you need a settled, mature library or a no-code tool, factor in that it is an early v0.1.x release with documented CSS and layout limits.
They occupy the same "HTML to Word" space with different trade-offs. DOM-docx emphasizes structural fidelity (real Word constructs, tested against a visual-regression loop) and a light core with optional browser-based style resolution. html-to-docx is a popular Node peer; Pandoc is a heavier universal converter covering many formats. The best pick depends on your stack and fidelity needs.
Not for its default inline path, which runs on Node.js 20+ with just docx, cheerio, and fflate. Playwright and Chromium are optional, needed only for the "computed" style mode (resolving style blocks and CSS classes) or for rasterizing complex SVG and canvas to PNG.
No. DOM-docx is a converter — it turns HTML you already have into a Word file, and its job ends there. It generates no text, images, or video and publishes to no platform. To create content and distribute it across platforms you would use a content engine like Kompozy, then optionally convert its HTML output with DOM-docx.
It is capable but young — a v0.1.x release with several documented limits (no external stylesheets on the inline path, no web fonts, no CSS grid/float, no forms, no table rowspan). For straightforward HTML it works well; for complex layouts, test against your real documents and check the GitHub repo for the current feature set before depending on it.
Developers who need an HTML-to-Word conversion step should use DOM-docx (or html-to-docx or Pandoc). Creators and founders who want to generate content and publish it across platforms should use Kompozy — it is a content generation and publishing engine, not a converter. They sit at different points in the workflow and can be used together.