Today, we are releasing Word to markdown converter library. It’s open source and published under Apache 2.0 license. It uses our layout engine, so it can return accurate, per-page markdown blocks (with headers, footers, and image references). We also handle fonts (Google fonts as fallback) or let you pass your font files upfront for accurate content measurement.

To our surprise, Word to per-page Markdown conversion is not a solved problem even in 2026! We initially faced this friction when preprocessing Word documents for agentic workflows. For our use case, it was important to represent per-page content in markdown. Initially, we ended up using LibreOffice sidecar to convert to PDF and then using .pdf -> .md library. This was not ideal given that LibreOffice sidecar that was sitting idle most of the time.

This issue is addressed with docx-to-markdown library. it can be used directly in your Typescript ingestion pipeline. Try with your docs at https://www.docx-editor.dev/solutions/word-to-markdown.

(if you catch any bugs please let us know in the comments / or file gh issues)

Comments URL: https://news.ycombinator.com/item?id=49728477

Points: 5

# Comments: 5

The repo has actually been public for ~3 months, but we only launched the project homepage https://www.docx-editor.dev recently, so search engines are still catching up.

> I was scouring the internet for something like this and couldn't find it.

Interested to hear how can we make it more discoverable? What keywords were you searching for ?

The OOXML spec gets you far but doesn't cover 100% of how Word renders things. Community feedback has helped a lot here, users attach docs (in gh issues) that break rendering, we can reproduce against Word, fix the engine, and keep tightening fidelity.

A lot of existing approaches convert .docx into HTML and lose document semantics along the way. Our editor parses OOXML directly and uses its own rendering+layout engine to produce paged documents with html/css. Edits round-trip back to .docx, so you’re always editing the document, not its representation.

The core rendering engine is framework agnostic, with React and Vue ui adapters on top.

It’s Apache 2.0. Happy to answer questions.

Comments URL: https://news.ycombinator.com/item?id=48228411

Points: 107

# Comments: 17

We are building this because we such library it in our core business, and a lot of other engineers seem to need it too. We have contributors showing up with bug reports and fixes, and real interest from people building apps around .docx docs.

My previous show hn post (https://news.ycombinator.com/item?id=46947229) got a lot of skepticism because we're developing heavily with AI, but with active community feedback and proper ai oversight (mostly me), I'm super proud of what we have now.

Every other JS DOCX editor I found was either abandoned or commercial. I couldn't find a solid MIT-licensed option.

For now, we mostly rely on testing with our own and customer docs. In practice, we were seeing solid results after a couple of days of keeping Claude working in the loop and giving lots of feedback: .docx files along with screenshots annotated to highlight what didn’t work.

As an experiment, we gave Claude Code the OOXML spec, a concrete editor architecture, and a Playwright-based test suite. The agent iterated in a (Ralph) loop over a few nights and produced a working editor from scratch.

Core text editing works today. Tables and images are functional but still incomplete. MIT licensed.

Comments URL: https://news.ycombinator.com/item?id=46947229

Points: 130

# Comments: 44