How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
I do a lot of backend document (docx file) generation work, and updating our templates and backend code is one of my least favorite development tasks. Cryptic errors, minute-plus rebuild loops. I’d much prefer building these reports in JS rendered HTML (e.g., Vue or React), but existing HTML-to-docx libraries in the OSS ecosystem don't produce output that's actually valid, editable Word structure.
I'd had good luck applying Karpathy's Autoresearch pattern (agent runs iterations against an objective score, keeps what improves, discards what doesn't) to a couple of other problems, and figured OOXML fidelity was a good fit.
The Autoresearch process goes like this: render HTML and take a screenshot, use dom-docx to convert to docx, rasterize the docx file with LibreOffice and take another screenshot, score the browser HTML screenshot vs LibreOffice screenshot and measure layout fidelity + editability + speed as a quality metric, feed score back in, and repeat to drive higher fidelity within the constraints of editability and performance. It’s a beautiful thing to watch.
Burned some tokens and ran that loop against 37 real-world HTML patterns such as nested lists, tables, flex layouts and blockquotes (stuff that often breaks converters) and "brute forced" my way to what I hope is a high-fidelity HTML to docx converter.
A few things about where it landed:
- Native OOXML output, real Word structure, not a screenshot or a 1x1 table pretending to be a document
- Works in Node, in the browser (no Playwright needed for the default path), and as a CLI (npx dom-docx input.html -o output.docx)
- MIT licensed
- Full benchmark methodology + results vs the established OSS alternatives: https://github.com/floodtide/dom-docx/blob/main/docs/BENCHMA...
Live demo if you want to test HTML conversion in the browser: https://dom-docx.com
Happy to answer anything about the scoring loop or anything else.
PS: This is the first thing I've open sourced and I'm excited to see where it leads!
Just adding, since I don't see it mentioned in the readme, that its written in Typescript. That's what makes this interesting. I imagine Pandoc can do this but its not Typescript (its Haskell).
I have done something similar for PPTX, keeping the fidility intact was really challenging with computed values & OOXML counterparts and again challanges with different XML implementations like that of MS & Libre..
OOXML DOOM. WAD file corrupts, Word "repairs" it, half textures gone, boss fight now silent. Someone's gonna deploy this as prod build system eventually.
Used docx-js style manual XML fiddling for years before switching to something like this. Real gotcha: track-changes and comments metadata get stripped by most tools. If DOM-docx preserves revisions on round-trip, that's the actual hard part nobody solves.
I did everything with the Cursor $20 plan and the Claude Code $20 plan, so in this particular case it wasn’t actually that many tokens. This was over the course of about four weeks of weekend and evening work.
Right, but browsers already shipped print CSS support in the 90s and nobody used it then either. Same story with RSS, same story with semantic HTML. Tooling that route around dev laziness tends to win by default.
Broken printing is a failure/intention of website developers. It’s very easy to define print styles with a `@media print {…}` CSS query. Few sites use it.
Doubt it happens. Round-tripping through docx is where these tools go to die — Word's format has decades of cruft that never maps cleanly back from HTML. Cool project either way, just don't hold your breath on that direction.
Used docx generation at two jobs, both times we ended up hand-patching XML because some library choked on nested tables or track changes. If this actually round-trips through real Word without corrupting files, that's the whole ballgame.
I do a lot of backend document (docx file) generation work, and updating our templates and backend code is one of my least favorite development tasks. Cryptic errors, minute-plus rebuild loops. I’d much prefer building these reports in JS rendered HTML (e.g., Vue or React), but existing HTML-to-docx libraries in the OSS ecosystem don't produce output that's actually valid, editable Word structure.
I'd had good luck applying Karpathy's Autoresearch pattern (agent runs iterations against an objective score, keeps what improves, discards what doesn't) to a couple of other problems, and figured OOXML fidelity was a good fit.
The Autoresearch process goes like this: render HTML and take a screenshot, use dom-docx to convert to docx, rasterize the docx file with LibreOffice and take another screenshot, score the browser HTML screenshot vs LibreOffice screenshot and measure layout fidelity + editability + speed as a quality metric, feed score back in, and repeat to drive higher fidelity within the constraints of editability and performance. It’s a beautiful thing to watch.
Burned some tokens and ran that loop against 37 real-world HTML patterns such as nested lists, tables, flex layouts and blockquotes (stuff that often breaks converters) and "brute forced" my way to what I hope is a high-fidelity HTML to docx converter.
A few things about where it landed:
- Native OOXML output, real Word structure, not a screenshot or a 1x1 table pretending to be a document - Works in Node, in the browser (no Playwright needed for the default path), and as a CLI (npx dom-docx input.html -o output.docx) - MIT licensed - Full benchmark methodology + results vs the established OSS alternatives: https://github.com/floodtide/dom-docx/blob/main/docs/BENCHMA...
Live demo if you want to test HTML conversion in the browser: https://dom-docx.com
Happy to answer anything about the scoring loop or anything else.
PS: This is the first thing I've open sourced and I'm excited to see where it leads!