WordCraft: Open-Source Rust Clone of Word [2026]

WordCraft is four days old. Microsoft Word has been shipping since 1983, which puts it at 43. That gap, four days against four decades, is the entire story of WordCraft: an open-source, clean-room reimplementation of Microsoft Word, written from scratch in Rust rather than forked from any Microsoft source code. And it is more interesting than it first looks.

Let me be clear about what we actually know, because the hype-to-evidence ratio on this one is high. The primary evidence is a single demo video from the channel Heroic Steps, titled "WordCraft: I Opened This Free Word Clone's File in Real Microsoft Word." The test was simple and smart: create a document in WordCraft, save it, open the result in genuine Microsoft Word, and see whether the file survives the round trip. That is the one claim worth taking seriously, and the one worth stress-testing.

What an open-source WordCraft actually is

Strip away the branding and WordCraft is a word processor that aims to read and write Word's native file format while reproducing enough of Word's behavior to feel like a drop-in. "Clean-room" is the load-bearing word. A clean-room reimplementation means the authors studied the original's observable behavior and file format, wrote a specification from that study, and then implemented against the spec without ever touching Microsoft's copyrighted source. It is legal independent creation, not copying.

Writing it in Rust is a deliberate choice, not a fashion statement. A word processor is a document model, a layout engine, a rendering pipeline, and a file-format parser all wired together, and every one of those is a classic memory-safety minefield in C++. Rust's ownership model removes an entire category of the crashes and parsing exploits that have plagued office software for decades. If you are going to attempt the single most bug-prone application category in desktop software, starting from a language that eliminates use-after-free is the pragmatic move.

A four-day-old word processor can open a file. Matching four decades of Word's edge cases is the part that takes years.

That is the honest framing. Opening a hello-world .docx in Word on day four is a real achievement and a terrible predictor of where the project lands on day four hundred.

WordCraft is not Google's Wordcraft

Here is the thing nobody searching for this will figure out on their own: there are two unrelated projects named Wordcraft, and they have nothing to do with each other.

The one in this post is the Rust, clean-room Word clone. The other is Wordcraft from Google's PAIR team, an LLM-powered editor for creative short-story writing. That project has been on GitHub since 2023, carries an Apache-2.0 license, and sits around 331 stars. It is a writing-assistance research prototype, not a Microsoft Office competitor. If you land on the PAIR repo expecting a free Word, you are in the wrong place. Land here expecting an AI story tool, same problem in reverse.

The name collision matters for anyone evaluating either tool. They solve different problems, ship under different licenses, and come from completely different lineages. Treat the shared name as a coincidence and move on.

The clean-room lineage: from BIOS to Wine to WordCraft

WordCraft did not invent its legal strategy. It inherited one of the best-documented methodologies in computing history, and understanding that lineage tells you more about its prospects than any demo can.

The canonical precedent is Phoenix Technologies' 1984 clean-room clone of IBM's PC BIOS. One team read IBM's BIOS and wrote a behavioral spec; a lawyer scrubbed that spec for anything copyrightable; a second team that had never seen IBM's code implemented against the spec. The result was a legal, compatible BIOS that let Compaq and the entire PC-clone industry exist. That firewall between the team that observes and the team that builds is the heart of clean-room design, and it defends against copyright, though notably not against patents.

The living descendants are instructive:

• Wine, led for decades by Alexandre Julliard, reimplements the Windows API through black-box testing to stay clear of copyright. Its GitHub mirror shows roughly 4,246 stars and 1,445 forks, though the canonical WineHQ GitLab is far larger. Wine is genuinely useful today, more than 30 years in.
• ReactOS, a clean-room reimplementation of the Windows NT API, sits at about 18,197 stars and 2,244 forks on GitHub, with release 0.4.16 landing in August 2026. After roughly three decades it is still, by its own maintainers' label, "Alpha quality."
• The reverse-engineering discipline itself traces back to people like Andrew Tridgell, whose black-box approach on Samba became the template for inferring a protocol or format purely from its observable behavior.

The pattern is unambiguous. Clean-room clones of a moving, commercial target are achievable and legal, and they take a very long time to become complete. Wine is useful but still chases edge cases. ReactOS is a 30-year alpha. WordCraft is four days old.

Why cloning Word is really a fight with .docx

The hard part of a Word clone is not the cursor blinking or the bold button. It is the file format.

Word's native format is Office Open XML (OOXML), standardized by Ecma as ECMA-376 and later by ISO/IEC as ISO/IEC 29500. The standardization was famously contentious, and the technical residue of that fight is the real obstacle. There are two flavors of the standard, Strict and Transitional. Microsoft Office 2010 only partially supported the ISO Strict variant, and Office 2013 and later still default to saving as Transitional for backward compatibility. In plain terms: the official standard and what Word actually writes to disk are not the same thing.

So a clean-room .docx implementation has to target the format Word really emits, legacy compatibility shims and all, not the clean standard on paper. That is why fidelity is the whole ballgame. The reasons this is brutal:

1. The real-world format is Transitional-by-default, so you are implementing decades of accreted compatibility behavior, not a clean spec.
2. A .docx is a ZIP container of XML parts, relationships, and embedded media, and a single malformed relationship can make Word refuse the file.
3. Styles, numbering, and theme inheritance cascade in ways that are easy to get subtly wrong and hard to notice until a document looks broken three pages in.
4. Tracked changes, comments, fields, and content controls each carry their own schema baggage.
5. Equations are their own universe. Word serializes math as Office MathML (OMML), a dialect distinct from the W3C MathML that LibreOffice and browsers expect, so a faithful clone has to translate between two math representations before anything renders correctly.
6. Round-tripping is the killer. A file that opens is easy; a file you can open, edit in Word, save, and reopen in WordCraft without drift is the actual bar.

Then there is the mc:AlternateContent markup Word uses to ship two renderings of the same element side by side, one modern DrawingML and one legacy VML fallback, so older and newer readers each find something they understand. A clone that ignores that wrapper renders a blank box where a shape should be, and the document still technically "opens." This is one of those things where the boring answer is the right one. The feature that sells the project in a 10-minute video, opening a file in real Word, is the 2% demo on top of a 98% iceberg of format compatibility.

Did AI write WordCraft in four days?

Four days is the detail everyone fixates on, and they should. A word processor is not a weekend CRUD app. Four days for a Rust codebase that produces a Word-readable .docx strongly suggests heavy AI-assisted coding, the workflow a lot of people now call vibe coding.

I do not say this to dismiss it. The multi-agent pipeline I built and run for this blog has shipped 261+ posts, and I have watched AI-assisted coding compress work that used to take weeks into days. Fast is real now. Tools like Claude Code and the broader wave of agentic AI make a four-day prototype of something ambitious entirely plausible. We have seen the same traction curve elsewhere; one Claude Code skill on this site's radar hit 6,500 stars in four days.

But speed cuts both ways. A file-format parser is exactly the kind of code where "it compiles and the happy path works" hides a long tail of silent corruption. The open-source world is already wrestling with the downside, from AI-generated code flooding open source to the provenance and AI security questions that come with code no human fully reviewed. For a clean-room project specifically, provenance is not a nicety. It is the legal foundation. If an AI model was trained on Word-related code or leaked internals, the clean-room firewall gets murky fast. Nobody has answered that question for AI-assisted clean-room work yet, and WordCraft is a live test case.

In my own pipeline I learned that deterministic gates before any LLM review catch more than doubling the review model's size. Fidelity testing for a file format is the same discipline: you want a mechanical, repeatable check, not a vibe.

How to actually test WordCraft's file fidelity

If you want to evaluate WordCraft honestly rather than trusting a demo, run the round trip yourself across three engines. This is the written companion to what the Heroic Steps video did, and it is the only test that matters.

• Create in WordCraft, open in Word. Use a document with real structure: headings, a numbered list, a table, a footnote, an embedded image, and tracked changes. Not "hello world."
• Open the same file in LibreOffice. LibreOffice is the dominant non-clean-room open-source Word alternative, forked from OpenOffice.org in 2010 (its GitHub mirror sits around 4,509 stars). It is a strong second opinion on whether the file is standards-shaped or Word-specific.
• Open it in Google Docs. A third, independent OOXML importer. If all three agree, the file is genuinely portable; if only Word is happy, WordCraft may be emitting something idiosyncratic.
• Round-trip it. Edit in Word, save, reopen in WordCraft. Then reverse. Watch for style drift, lost formatting, and mangled numbering.
• Diff the ZIP. Unzip the .docx and inspect the XML parts. This is where you see whether WordCraft writes clean relationships and valid parts or hacks that happen to render.

Based on the reproducible methodology I maintain for the local-LLM benchmark database at kunalganglani.com/llm-benchmarks, where every benchmark post ships with a methodology appendix so anyone can rerun the numbers on their own hardware, I have learned that a fidelity claim without a repeatable procedure is marketing, not evidence. A file-format test is the same discipline. The five steps above are a protocol, not a vibe, and they should produce the same verdict on your machine as on mine. If a demo video cannot be reduced to a procedure a stranger can repeat, treat the result as a screenshot, not a benchmark.

A tool that passes all five is not a toy. A tool that only passes the first is a demo. Most four-day-old projects are the latter, and that is fine, as long as nobody oversells it.

What the precedents say about WordCraft's odds

Put WordCraft next to the field and the realistic picture snaps into focus.

AbiWord is the cautionary tale worth sitting with. It is an independent open-source word processor that still runs on Linux and ReactOS, but its Windows port died from lack of maintainers and its macOS build has been stuck on version 2.4 since 2005. A full word processor is a maintenance commitment measured in developer-decades, and without a well-funded foundation behind it, the long tail of compatibility work is where enthusiasm goes to die. The Document Foundation behind LibreOffice coordinates hundreds of contributors and ships a major release on a roughly six-month cadence; that institutional rhythm, not a clever demo, is what keeps a format-compatible word processor alive year after year. Collabora Online, the browser-based, self-hosted descendant of LibreOffice, exists precisely because sustaining this class of software commercially is that demanding.

There is also raw calendar math. Word shipped in 1983; 43 years is roughly 15,700 days. A four-day-old project is competing against something with close to a 3,900x head start in development time. That does not make WordCraft pointless. It makes the "replace Word" framing premature by a wide margin.

My read, having spent 2025 running a multi-agent pipeline that leans hard on AI-assisted coding, is that WordCraft is a genuinely cool proof of concept and a useful public experiment in AI-assisted clean-room engineering. Whether it becomes the next Wine or the next abandoned four-day repo depends entirely on whether a community forms around the unglamorous 98%, the open-source sustainability problem that kills more projects than any technical wall. As Simon Phipps, former president of the Open Source Initiative, has long argued, open document formats are worth fighting for on their own merits, independent of any one implementation.

If you build office software or anything that parses hostile file formats, WordCraft is worth watching for the methodology, not the marketing. And if you are tempted to dunk on a four-day-old Word clone, remember that every indispensable clean-room project in computing, including the one that made PC clones legal, started exactly this small. The question is never whether the demo works. It is who shows up for year three. Most people watching the video will have forgotten the name by then. The handful who do not are the ones who will decide whether WordCraft matters.

Photo by Joan Gamell on Unsplash.