I disagree that this submission has no value at all or that it should be auto-banned — there is a difference between thoughtless vibe-coding and spec-driven coding, guarded by tests. It seems from the next thread that this project is hopelessly outmatched by the sheer complexity of taking on something as the Docx spec, but this project has value, and for someone, it may be all that they need.
However, I do agree with your point about live debugging. In light of that, I prefer to treat this submission as a curiosity about current model capabilities, and let the authors keep improving this project if they find it worth their time.
Let's be more respectful to the differing goals of people
Seconded. I could ask the LLM myself and see what it comes up with in 5 minutes, not to mention that all of this was done 1000 times already so I have no interest of doing so.
Also, it's effortless. Not interesting at all if you can't share any insight about the project, because you don't know how it works under the hood and how many architectural problems were solved (or not)
The real tragedy is that I can only give a single upvote. This post needs to be added to the HN guidelines, I feel.
We are being overwhelmed with slop. Not even original slop, but carefully specced slop that poorly replicates some existing functionality, but as a SaaS.
This is the 90s equivalent of "Doing $FOO, but on the internet", only it's "Copying $FOO, but with added costs as a SaaS".
That it is AI is just another black mark against it.
Ah these poor fools. Having built this exact product (OOXML compatible editor in React) before, it took all of two minutes to find a bug. The issue is that the OOXML spec is not in fact definitive - Word is, and trying to implement it from the spec will produce something that works maybe 80% of the time then fall over completely when you hit one of hundreds of minor, undocumented edge cases. Assuming of course that CC did not just hallucinate something. And then there's the more fundamental problem that HTML/CSS has unresolvable incompatibilities with OOXML. This is why Google Docs for instance use canvas for rendering.
Acrobat at least hasn't been relevant for over a decade outside of niche concerns (like javascript-enabled pdfs, which I have seen exactly twice in the wild... these should be illegal by the way). You can't say the same about microsoft.
This is not true IME, because PDF and PostScript are so tightly coupled. If your PDF renderer doesn't tightly align with Acrobat, it's highly likely to not print correctly, hence Acrobat __is__ the spec.
I feel the pain having had to build a browser based pdf editor with features not found anywhere else. React was hammered into working and turned out pretty good. But my god, it was quite a journey. As with all enterprise projects, this one was shelved because business changed their minds. Two years of figuring it out just wasted …
IE was used well until EOL and is still being used in some places. I have no doubt Adobe Acrobat is the same way. Likely few if any new users but old ones will keep using what they're familiar with.
When I saw the title I couldn't help but ask myself: how?
The spec is over 5000 pages long - no way in hell a human could parse this in a reasonable timeframe and no agent today has nearly the necessary context.
EDIT: also, like you said: the spec is secondary to the implementation and was only published (and not even in complete form originally!) because Microsoft was asked by the EU to do that.
Fair point, we know the editor isn't yet 1:1 with Word. When you built yours, was Word your source of truth (reverse-engineering sense), or did you stick to MS-OE376? And any recommended process for systematically uncovering those undocumented edge cases?
We went out and used our editor against our and customer's documents. The Open part of OOXML makes as much sense as the Open in OpenAI. Microsoft made OOXML available to fend off an antitrust lawsuit, there is no incentive for them to make it actually easy to build competing editors off their specification.
FWIW the bug I found is that your comment parser assumes the w:date attribute represents a useful timestamp of when comments are made. It does not - a bug in Word causes it to save it as ISO8601 local time but _without timezone_, rendering it useless if more than one user across different timezone edits the document. Instead, you need to cross reference the comment with a newer comment part and find a dateUtc attribute. The above is, of course, completely undocumented.
We don’t have a formal '% compatibility' metric yet, but it’s on our radar as a feedback loop mechanism for self-improvement.
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.
This is a very naive mindset, getting the last 10% is going to be 90% of the work. Learn from other projects that have tried and failed. I can guarantee you LibreOffice was not built with "our own and customer docs" as a test harness.
The threshold for caring about experiments is exponentially higher in 2026 thanks to half baked vibe slop.
Non-functioning software and demoware comes fast and cheap, regardless of author.
> we gave Claude Code the OOXML spec
Having used the former a lot and read the latter in detail, uhhh…
Trim down the claims here, clarify the editor subset you plan to be supporting, and map the “last 90%”’s to honestly reflect the product you are pushing.
If “tables” and “images” aren’t there I’m quite skeptical about content controls and other key OOXML constructs being addressed meaningfully. The full OOXML footprint chokes OpenOffice out of procurements, rich OOXML documents choke half-way-there implementations (which was the whole point of the format).
As is pointed out elsewhere in the thread - there are fundamental constraints that have kept Google, Apple, and others from pursuing this route. Relatively simple docs are one thing, but OOXML is full of dragons and parity with Word has eluded more than a few tech giants.
I agree with everything in this comment - FWIW, I was on the standards bodies in my country in 2008/2009 to establish a national standard for word processing documents.
We debated the OOXML spec in as much detail as time allowed, but we still didn't get through the entire behemoth of a thing.
ISTR that Microsoft representatives were also on the same subcommittee, and, but the MS rep was pushing very hard indeed to standardise on OOXML.
Too bad the OOXML format, itself, has MS-proprietary binary blobs built into the specification as part of the format.
ISTR we submitted a recommendation of standardising on ODF.
How far can Claude can take this beyond a cool demo.
Does it become exponentially harder to add the missing features or can you add everything else you need in another two days? I'm guessing the former but would be interested to see what happens.
Are you going to continue trying? I ask because it's only been two days and you're already on Show HN. It seems like if you waited for it to be more complete, it would have been more impressive.
Excellent work! To put out the importance of the project - as of today there is not many google docs/word online alternative that is completely open source.
I'm yet to dig the code on how pagination is implemented but if the page breaks mimick word's - this is huge!
Would be more impressive if this was done for something obscure like Microsoft Visio. Theres countless oss ms word editors/libs Claude probably ripped off
Yup that’s why I suggested it. The vsdx schema is notably complex and I don’t see a lot of code examples in the wild. I seriously doubt an llm would be able to output working code for it. Docx is a common use case and a quick google search yields multiple popular libraries that understand the format. Anyways, cool that an llm was able to output a functional docx editor, but that’s certainly not impressive or a groundbreaking feat by any means
Thank you for sharing this and making it open source! I appreciate that when clicking the link you end up immediately in the tool. I saved it. This surely will be useful at some point.
Interesting post to link to, given the subject matter. Those Simpsons images don't have any credit, so I'm highly suspicious that they've been generated by AI and are violating copyright.
I would have liked to see the feedback loop and harness instead of the end product. 12 years back, I was opening the 12000 page ECMA OOXML format and also reverse engineering Word's output (half my time spent from undocumented crap) and having "unit tests" to generate Docs which I had to check by eye.
Someone has to do it:
Please auto-ban any "We gave Claude/Gemini/Grok/OpenAO/Qwen/Mistral/WhateverLLMAI the spec and..."
"and..." resolves to:
- "and now we have this impressive result you won't believe!"
100% of the time this is attention seeking, live debugging - no value at all.
Don't waste people's time. Any sound and reasonable story about results without misusing the public's eye is welcome, for example:
- One year after - 10 hard problems we found - extensive pro/contra comparison with other solutions - maintaining such a AI app for one year
Otherwise: please auto-ban.
I disagree that this submission has no value at all or that it should be auto-banned — there is a difference between thoughtless vibe-coding and spec-driven coding, guarded by tests. It seems from the next thread that this project is hopelessly outmatched by the sheer complexity of taking on something as the Docx spec, but this project has value, and for someone, it may be all that they need.
However, I do agree with your point about live debugging. In light of that, I prefer to treat this submission as a curiosity about current model capabilities, and let the authors keep improving this project if they find it worth their time.
Let's be more respectful to the differing goals of people
Seconded. I could ask the LLM myself and see what it comes up with in 5 minutes, not to mention that all of this was done 1000 times already so I have no interest of doing so.
Also, it's effortless. Not interesting at all if you can't share any insight about the project, because you don't know how it works under the hood and how many architectural problems were solved (or not)
At this point I agree, this is brogramming and its getting boring.
> brogramming
Is it back? I remember 2011 it had a high time in an ad agency I was working back then :-D
The real tragedy is that I can only give a single upvote. This post needs to be added to the HN guidelines, I feel.
We are being overwhelmed with slop. Not even original slop, but carefully specced slop that poorly replicates some existing functionality, but as a SaaS.
This is the 90s equivalent of "Doing $FOO, but on the internet", only it's "Copying $FOO, but with added costs as a SaaS".
That it is AI is just another black mark against it.
Ah these poor fools. Having built this exact product (OOXML compatible editor in React) before, it took all of two minutes to find a bug. The issue is that the OOXML spec is not in fact definitive - Word is, and trying to implement it from the spec will produce something that works maybe 80% of the time then fall over completely when you hit one of hundreds of minor, undocumented edge cases. Assuming of course that CC did not just hallucinate something. And then there's the more fundamental problem that HTML/CSS has unresolvable incompatibilities with OOXML. This is why Google Docs for instance use canvas for rendering.
I feel your pain. PDF applications have the same problem. The thousand page PDF spec isn't actually the spec, Acrobat is the spec.
Acrobat at least hasn't been relevant for over a decade outside of niche concerns (like javascript-enabled pdfs, which I have seen exactly twice in the wild... these should be illegal by the way). You can't say the same about microsoft.
This is not true IME, because PDF and PostScript are so tightly coupled. If your PDF renderer doesn't tightly align with Acrobat, it's highly likely to not print correctly, hence Acrobat __is__ the spec.
I feel the pain having had to build a browser based pdf editor with features not found anywhere else. React was hammered into working and turned out pretty good. But my god, it was quite a journey. As with all enterprise projects, this one was shelved because business changed their minds. Two years of figuring it out just wasted …
do people still use acrobat? since pds becoming prolific in browsers and word and stuff i mean
IE was used well until EOL and is still being used in some places. I have no doubt Adobe Acrobat is the same way. Likely few if any new users but old ones will keep using what they're familiar with.
When I saw the title I couldn't help but ask myself: how?
The spec is over 5000 pages long - no way in hell a human could parse this in a reasonable timeframe and no agent today has nearly the necessary context.
EDIT: also, like you said: the spec is secondary to the implementation and was only published (and not even in complete form originally!) because Microsoft was asked by the EU to do that.
Fair point, we know the editor isn't yet 1:1 with Word. When you built yours, was Word your source of truth (reverse-engineering sense), or did you stick to MS-OE376? And any recommended process for systematically uncovering those undocumented edge cases?
We went out and used our editor against our and customer's documents. The Open part of OOXML makes as much sense as the Open in OpenAI. Microsoft made OOXML available to fend off an antitrust lawsuit, there is no incentive for them to make it actually easy to build competing editors off their specification.
FWIW the bug I found is that your comment parser assumes the w:date attribute represents a useful timestamp of when comments are made. It does not - a bug in Word causes it to save it as ISO8601 local time but _without timezone_, rendering it useless if more than one user across different timezone edits the document. Instead, you need to cross reference the comment with a newer comment part and find a dateUtc attribute. The above is, of course, completely undocumented.
Can you say the name of the editor your worked on?
When you built this exact product, how long did it take you to reach 80% compatibility?
>> how long did it take you to reach 80% compatibility?
Honest question: when the formal spec isn't really a spec how do you even measure "80% compatibility"?
We don’t have a formal '% compatibility' metric yet, but it’s on our radar as a feedback loop mechanism for self-improvement.
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.
This is a very naive mindset, getting the last 10% is going to be 90% of the work. Learn from other projects that have tried and failed. I can guarantee you LibreOffice was not built with "our own and customer docs" as a test harness.
Arent there any commercial libraries available already?
Somehow this reminds me of PDF
> As an experiment
The threshold for caring about experiments is exponentially higher in 2026 thanks to half baked vibe slop.
Non-functioning software and demoware comes fast and cheap, regardless of author.
> we gave Claude Code the OOXML spec
Having used the former a lot and read the latter in detail, uhhh…
Trim down the claims here, clarify the editor subset you plan to be supporting, and map the “last 90%”’s to honestly reflect the product you are pushing.
If “tables” and “images” aren’t there I’m quite skeptical about content controls and other key OOXML constructs being addressed meaningfully. The full OOXML footprint chokes OpenOffice out of procurements, rich OOXML documents choke half-way-there implementations (which was the whole point of the format).
As is pointed out elsewhere in the thread - there are fundamental constraints that have kept Google, Apple, and others from pursuing this route. Relatively simple docs are one thing, but OOXML is full of dragons and parity with Word has eluded more than a few tech giants.
I agree with everything in this comment - FWIW, I was on the standards bodies in my country in 2008/2009 to establish a national standard for word processing documents.
We debated the OOXML spec in as much detail as time allowed, but we still didn't get through the entire behemoth of a thing.
ISTR that Microsoft representatives were also on the same subcommittee, and, but the MS rep was pushing very hard indeed to standardise on OOXML.
Too bad the OOXML format, itself, has MS-proprietary binary blobs built into the specification as part of the format.
ISTR we submitted a recommendation of standardising on ODF.
How far can Claude can take this beyond a cool demo.
Does it become exponentially harder to add the missing features or can you add everything else you need in another two days? I'm guessing the former but would be interested to see what happens.
Are you going to continue trying? I ask because it's only been two days and you're already on Show HN. It seems like if you waited for it to be more complete, it would have been more impressive.
Two very minor suggestions for the demo:
1. I don't know what the "Docxtemplater" button does, but it eats my document without warning and that's annoying.
2. It would be nice if the page came with some example .docx files we could see it work on.
There is HugeRTE, a fork of tinymce. I don't know how long they searched for a tinymce alternative
Is there any good open source that actually work with web docx editing ?
Excellent work! To put out the importance of the project - as of today there is not many google docs/word online alternative that is completely open source.
I'm yet to dig the code on how pagination is implemented but if the page breaks mimick word's - this is huge!
Thank you!
So it’s like Google Docs? What am I looking at exactly?
Yes, it's like Google Docs for .docx files. It's open-source, MIT-licensed, and runs fully in JS, so you can embed it in your app.
Every other JS DOCX editor I found was either abandoned or commercial. I couldn't find a solid MIT-licensed option.
More vibe coded slop on Show HN
Would be more impressive if this was done for something obscure like Microsoft Visio. Theres countless oss ms word editors/libs Claude probably ripped off
The schema Visio’s files save to is very complex.
There’s stuff like diagrams.net, but that’s not compatible.
Yup that’s why I suggested it. The vsdx schema is notably complex and I don’t see a lot of code examples in the wild. I seriously doubt an llm would be able to output working code for it. Docx is a common use case and a quick google search yields multiple popular libraries that understand the format. Anyways, cool that an llm was able to output a functional docx editor, but that’s certainly not impressive or a groundbreaking feat by any means
Thank you for sharing this and making it open source! I appreciate that when clicking the link you end up immediately in the tool. I saved it. This surely will be useful at some point.
Whats a Ralph loop?
https://ghuntley.com/loop/
Interesting post to link to, given the subject matter. Those Simpsons images don't have any credit, so I'm highly suspicious that they've been generated by AI and are violating copyright.
Yeah, what exactly is the top image supposed to be?
Also
>p.p.s don't miss out on free lifetime access
>Join thousands getting premium insights delivered weekly.
ai slop
[dead]
> Curious how you handled the undocumented Word behaviors that deviate from the spec.
That’s the neat part: they didn’t!
I would have liked to see the feedback loop and harness instead of the end product. 12 years back, I was opening the 12000 page ECMA OOXML format and also reverse engineering Word's output (half my time spent from undocumented crap) and having "unit tests" to generate Docs which I had to check by eye.