// the take
A TypeScript library for building and editing .docx files from Node or the browser, working close to the raw OOXML format rather than hiding it behind a simplified abstraction. It's for developers who need document generation as a feature of their own app — reports, CVs, contracts, invoices — and are willing to learn docx's object model (Document, Paragraph, Run, Section) to get full control over Word's formatting.
The feature set covers a lot of real OOXML: native Word charts, shapes and diagrams with connectors, track changes, comments, footnotes/endnotes, a table of contents, and citations rendered in actual Word bibliography styles (APA, MLA, Chicago) rather than plain text. Secondary modules like charts, shapes, watermarks, macros, and bibliography are published as separate entry points (docx/charts, docx/shapes, etc.) so an app that only needs paragraphs and tables doesn't pay for the rest in bundle size. The docx/html module converts rich-text-editor output (there are worked examples for Tiptap, Quill, CKEditor, Lexical, and Google Docs HTML) into the document's own paragraph and list styles instead of dumping raw markup. It also runs unmodified in Node and in the browser via UMD builds with no bundler required, which is a real engineering accomplishment for a library this deep into a binary-ish XML format.
This is a write-oriented library: there's no general way to read an arbitrary existing .docx back into a usable structure, only template-style placeholder patching, so round-tripping or extracting data from documents you didn't generate isn't really supported. The macros module produces genuine .docm files containing executable VBA — fine for a developer stamping a known macro into their own template, but a real risk if it ever gets wired into a pipeline where document content or macro code originates from user input, since you'd be programmatically generating code-executing files. The surface area has grown to cover charts, shapes, HTML import, macros, bibliography, and embedded OLE objects all sharing one core document model, maintained largely by one person (dolanmiu) by hand against the OOXML spec rather than through a validating layer, so upgrades touching more than basic paragraphs and tables carry real breaking-change risk and edge cases in less-common feature combinations (e.g. charts inside headers, macros plus track changes) are where you're most likely to hit a file Word calls corrupt.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →