Word's Version Control Is Broken — Use Markdown + Git Instead
You email a Word document to three reviewers. They each make changes with track changes on. Two days later, you have three slightly-incompatible documents in your inbox. You spend a morning manually merging them, accepting some changes, rejecting others, and somewhere in the process you accidentally drop a paragraph that the third reviewer added. The next day, the legal lead asks you to revert one of the edits — and you can't tell which version of the document had it the way they wanted. The whole process is, structurally, version control. It's just very bad version control. Markdown plus Git is what good version control looks like.
Track changes hell
Word's track changes is one of the most-used and most-broken features in office software. The problems start the moment more than two people are reviewing the same document.
The serial-review problem. Reviewer A finishes their pass and emails the file. While Reviewer B is working on it, Reviewer C asks for a copy too — so they get the version Reviewer A sent, not the in-progress version Reviewer B is editing. Now you have two parallel reviews on the same source document. When both come back, you have to manually reconcile them.
The change-of-a-change problem. Reviewer A changes "the company will" to "we will". Reviewer B then changes "we will" to "we shall". The track changes display becomes a tangled chain of insertions, deletions, and revisions of revisions. Reading the document with all changes shown becomes harder than just rewriting it.
The accept-all-and-lose-context problem. The most common resolution is to accept all changes and call it done. The problem is that you've now lost the audit trail of who changed what and why. Six weeks later, when someone asks why a key sentence was rewritten, the answer is unrecoverable.
The track-changes-leak problem. Word documents that have ever had track changes turned on often retain hidden change history even after "accept all". This metadata can leak in cleartext when the document is shared, exposing internal review history to external recipients — a known security incident class in legal and consulting industries.
The Final_v2_FINAL_really_final pattern
The other version-control failure mode in Word is the file naming convention that emerges when a team tries to track versions through filenames. The progression is universal:
Q3-Strategy.docx
Q3-Strategy-v2.docx
Q3-Strategy-v2-edits.docx
Q3-Strategy-v3.docx
Q3-Strategy-final.docx
Q3-Strategy-final-v2.docx
Q3-Strategy-FINAL.docx
Q3-Strategy-FINAL-revised.docx
Q3-Strategy-FINAL-v2.docx
Q3-Strategy-actual-final.docx
Q3-Strategy-final-FINAL.docx
Q3-Strategy-final-FINAL-jane-edits.docx
Q3-Strategy-final-really-final.docxEvery team has a version of this. The problem is structural: Word documents are binary blobs that don't diff cleanly, so the only way to preserve history is to keep multiple copies. The naming becomes a desperate attempt to communicate which copy is current.
The cost shows up in three ways. Storage bloat is the smallest of them. The real costs are the time wasted disambiguating versions ("is this the one with Jane's edits or the one before?") and the recurring "we shipped the wrong version" incident — almost universal in any team that uses this pattern long enough.
What real version control looks like
Git was built for source code. The capabilities it gives you for source code apply equally well to text documents — including Markdown documents:
Real diffs. Every change to the document is recorded as a diff: the exact lines that changed, in the exact order they changed, with the author and timestamp. You can read the history of any paragraph at any time.
Real branches. Three reviewers can work on three branches in parallel without any coordination overhead. Each makes their changes; each pushes their branch. The merge step is mechanical, not a manual reconciliation.
Real merges. When two reviewers edit different parts of the document, Git merges them automatically. When two reviewers edit the same paragraph differently, Git surfaces the conflict and asks you to choose — explicitly, with both versions side by side, instead of silently dropping one.
Real audit trail. Every commit has an author, a timestamp, and a message. Six weeks later, you can ask "why was this sentence rewritten?" and get the answer in seconds: the commit message that introduced the change, the commit that altered it, the discussion in the pull request that approved it.
Real reverts. If a change turns out to be wrong, you revert the commit. The document goes back to the previous state, atomically, with the revert itself recorded as part of the history.
None of this is possible with Word, because Word's binary format doesn't diff. Markdown's text format does.
Why Markdown specifically
Could you put a Word document under Git? Technically yes — Git will happily track any file. The problem is that Git's diff and merge are line-based, and Word's binary .docx format produces meaningless diffs. A two-character change to the visible text might appear as a complete rewrite of the underlying ZIP archive.
Markdown is plain text, line-oriented, and structurally simple. Git treats Markdown the same way it treats source code: every line is trackable, every change is reviewable, every merge is mechanical. The version-control story for Markdown is the version-control story for code, applied to documents.
The platform side is also mature. GitHub, GitLab, Bitbucket, and Azure DevOps all render Markdown natively in pull requests, in file views, and in commit diffs. Reviewers can see the document the way it will read, with the proposed changes highlighted inline, and approve or request changes the same way they would for code.
The migration workflow
Here's the practical path from a Word-document workflow to a Markdown-plus-Git workflow:
- Identify the documents that benefit. Not every document needs version control. The ones that do: anything reviewed by multiple people, anything with a long edit history, anything where audit trail matters (contracts, policies, technical specifications, board materials, regulatory submissions). Skip the one-off meeting notes.
- Convert existing Word documents to Markdown. Use /convert/word-to-markdown for the curated migration of documents you want polished, or Pandoc locally for bulk conversion of an existing archive. The conversion preserves headings, lists, tables, and formatting structure.
- Set up a Git repository. Either a private GitHub repository, a self-hosted Gitea instance, or a corporate GitLab. Convention: one repository per knowledge area (legal, engineering, marketing, operations) rather than one giant repository for everything.
- Establish a review workflow. Reviewers fork or branch the document, make their edits, and open a pull request. The merge step uses Git's machinery — no email back-and-forth, no manual reconciliation.
- For documents that need to ship as Word for external recipients, convert the final Markdown back to DOCX with Pandoc (
pandoc -f gfm -t docx final.md -o final.docx) at the moment of delivery. Or convert to PDF with /convert/markdown-to-pdf for read-only distribution. The source of truth stays in Git.
Honest scope
The web tool at /convert/word-to-markdown handles the per-document conversion. It does not set up Git for you, does not host your repository, does not run your review workflow. Those are existing tools you already have access to (GitHub, GitLab, etc.) — the conversion is the only piece that's been a workflow gap. The recommendation is honest: conversion is the bottleneck; the rest of the version-control infrastructure is mature and easy to adopt.
For teams that aren't ready to live in Git directly, the intermediate option is a wiki platform that ingests Markdown and provides a Git-style edit history (Outline, BookStack, GitBook). You get the diff/history/audit story without forcing the whole team to learn Git CLI.
The cultural shift
The hardest part of moving from Word to Markdown + Git is not the tooling. It's the cultural shift away from "the document is what's in this file" to "the document is what's in the latest commit on the main branch". Several behavioural patterns shift:
- Discussion moves to pull requests. Instead of debating in email threads about a document, the discussion happens inline on the proposed change. Decisions are recorded next to the change they affected.
- Merging stops being scary. Once people learn that Git will surface real conflicts and merge non-conflicts automatically, the manual reconciliation step disappears. Three reviewers can work in parallel without anyone being the bottleneck.
- Versions become rare. The Final_v2_FINAL filename pattern dies because there are no versions of the file — there's one file, with a complete history of how it got to its current state.
Cross-format pattern
The Word version-control problem is one specific case of the broader "binary formats are hostile to collaboration" pattern. The same dynamic affects spreadsheets, slide decks, and design files — though the alternative tooling for those is less mature than for documents. For documents specifically, the path is clear: text formats win for collaboration, Markdown wins among text formats because it carries enough structure to render usefully without sacrificing diffability.
For background on the AI-side benefits of the same shift, see Word documents are AI-hostile and you can't feed 500 Word docs to AI. For the CMS-side benefits, see the Word-to-CMS formatting nightmare. For the broader case for converting documents into Markdown for archival and search, see your company has thousands of Word docs nobody can find.
The honest summary
You don't need to convert your entire organisation to Git overnight. Pick one document type that hurts — the contracts, the policies, the technical specifications, the board materials. Convert the existing archive to Markdown with the web tool or Pandoc. Put it in a Git repository. Run your next review through pull requests. Six months later, the answer to "who changed this paragraph and why" stops being "I'd have to dig through fifteen email threads" and starts being a five-second blame on the affected line. That's what real version control looks like, and Word does not provide it.