Everything runs in your browser. We never see your files. How we prove it →
Document Diff Tools
Markdown comparison is live today — source and rendered output side by side — with PDF, Word and HTML comparison still to come.
- Markdown DiffCompare two Markdown files as source and as rendered preview. Perfect for docs and README changes. Fully client-side, nothing uploaded.
- PDF ComparesoonNot built yet — this page will link it the day it ships.
- Word Document ComparesoonNot built yet — this page will link it the day it ships.
- HTML DiffsoonNot built yet — this page will link it the day it ships.
About document diff tools
Documents differ from code in what a reader counts as a change. Nobody reviewing release notes cares that a paragraph was rewrapped or that an author switched underscores for asterisks; they care that a date moved and a caveat disappeared. Comparison built for documents therefore has to separate the file from the reading experience the file produces.
Markdown Diff is the tool that exists in this category now, and it answers both questions at once: a source view for anyone reviewing the file as a file, and a rendered view marking only the blocks whose published output genuinely differs. That covers README files, changelogs, docs-site pages, static-site content and anything else authored as plain text with light markup.
The rest of the category is not built. PDF Compare, Word Document Compare and HTML Diff are on the roadmap and appear on this page as names without links, because there is nothing behind them to visit yet. Saying otherwise would waste your click.
Which view to read, and what to do meanwhile
With one document tool live, the choice that matters is which of its two panes to trust. Read the rendered comparison when you are approving what gets published: it treats two spellings of the same heading as identical and flags the paragraph whose wording actually shifted. Read the source comparison when the file is under review as a file — in a pull request, or a docs repository with a house style — because there a switch from reference links to inline links is a real change somebody may want to discuss. Most reviews use both, starting rendered and dropping to source to pin down a word.
Until Markdown Diff has company, the workable route for a Word file or a PDF is to copy the text out of it and run that through Word-Level Diff. You lose layout, tracked changes and anything in a table cell that depends on position, but you keep every word — enough to answer whether a clause was edited between two versions.
Drafts stay unpublished
The defining trait of a document worth comparing is that at least one version of it is not public yet: a migration guide naming a specific customer, a policy revision in review, a manuscript, an announcement embargoed until next week. Handing that to a service that keeps a copy is the wrong move, and here there is nothing to hand over — parsing, sanitising, rendering and diffing all happen in the page you already loaded, with no draft storage and no sign-in behind it. Open your browser's network tab while you use these tools — you'll see no request carries your content. The steps are written out here.
Frequently asked questions
Can I compare a PDF or a .docx file today?
Not directly — those tools are not built. The practical substitute is to copy the text out of both versions and compare that, which answers wording questions but not layout ones. Comparing the binary files themselves would tell you almost nothing useful, since both formats change internally on every save.
Does the rendered preview run anything from the file?
No. Output passes through a sanitiser before it reaches the page, so script elements, event-handler attributes and dangerous URL schemes are stripped. Ordinary embedded HTML that a Markdown author legitimately uses survives. That matters when the document you are reviewing arrived from a contributor you have never met.
When will PDF and Word comparison ship?
There is no date to give, and inventing one would be worse than saying so. Both are genuinely planned, both are hard to do well entirely in the browser, and both will appear on this page as links the moment they exist. Until then the names sit here unlinked as a statement of intent, not availability.
What about front matter and MDX?
YAML front matter is treated as source text, so an edited slug, date or title shows up as a line change — usually what you want. MDX components are not evaluated; they appear as literal tags. For MDX files, work in the source pane and ignore the preview.