Everything runs in your browser. We never see your documents. How we prove it →
Markdown Diff — Compare Markdown Files
Compare two Markdown documents twice over: once as the text an author typed, once as the page a reader will end up seeing.
How the same document gets compared twice
Markdown is a lossy notation, in the sense that many different sources render to byte-identical HTML. A heading can be written with a leading `#` or underlined with `===` on the next line. Emphasis takes an asterisk or an underscore. A link may sit inline or point at a reference definition three hundred lines below. Reflow a paragraph so its line breaks fall elsewhere and the output does not shift by a character. Hence two comparisons rather than one. The source view answers what the author typed, anchoring on lines and marking the words that moved inside each changed one. The rendered view answers what the reader will see, flagging only the blocks — headings, paragraphs, list items, table rows — whose output genuinely differs.
Rendering passes through DOMPurify before anything touches the page, so a document carrying an `onerror` attribute or a `javascript:` href is defused rather than executed — reassuring when the file arrived attached to a pull request you have not read yet. GitHub-flavoured constructs are handled: pipe tables, `- [ ]` task lists, and fenced code blocks, which stay single units so a blank line inside a fence never splits it into two paragraphs. When the wording is what you are judging and the syntax is beside the point, Word-Level Diff reduces the question to which words changed.
Drafts nobody outside the room should read
Documentation is usually written before the thing it documents exists publicly. A README for an unannounced product, a migration guide naming a specific customer, release notes carrying a date that has not been shared — all of these are ordinary Markdown files, and all of them are wrong to hand to a comparison service that keeps a copy. This one keeps nothing. Parsing, sanitizing, rendering and diffing all happen inside the tab you have open. Open your browser's network tab while you use this tool — you'll see no request carries your content. The verification walkthrough shows the two-minute check.
Documents that get read this way
- A technical writer reviewing a docs pull request starts in the rendered comparison to confirm the published page changes as intended, then flips to source and catches a reference-style link whose definition was deleted along with the paragraph above it.
- An open-source maintainer weighs a contributor's README rewrite against the version on main. Rendered output shows two paragraphs genuinely reworded; everything else is a reflow that a source-only view would have painted red for nothing.
- A product manager approving release notes checks the copy engineering drafted against the wording legal signed off on, block by block, without ever having to read Markdown syntax or ask what a fenced block is.
- A course author revising a module sets last term's lecture notes against this term's and uses table support to see which rows of the assessment schedule shifted, rather than re-reading forty pages for changed dates.
Frequently asked questions
Which of the two views should I trust?
It depends on the question. Reviewing what gets published? Read the rendered comparison, which ignores syntax choices that produce identical output. Reviewing the file as code — in a pull request, or a docs repo with a style guide — read the source, where switching `_italic_` to `*italic*` is a real change somebody may want to discuss.
Is my document sent anywhere?
No. The Markdown parser and the sanitizer are both bundled into the page and run over text that never leaves it. There is no draft storage and no sign-in, so closing the tab is the entirety of the cleanup. Our privacy page explains how to confirm that from DevTools in roughly a minute.
What are the limits on size and precision?
Live comparison covers about a megabyte of combined source, which is a substantial documentation set. The rendered side marks changes at block level rather than inside every inline span, so a single altered word lights up its whole paragraph — the source view is where you pin down the word. Images referenced by URL are shown, not fetched and compared.
Is rendering untrusted Markdown risky here?
Not meaningfully. Output goes through DOMPurify, which strips script elements, event-handler attributes and dangerous URL schemes before the preview is inserted into the page. Raw HTML that is merely unusual — a `<details>` block, an inline `<sup>` — survives, since embedded HTML is legitimate Markdown. Nothing in a compared file can execute or call out.
What about front matter and MDX?
YAML front matter is compared as source text, which is normally what you want: an edited slug or date surfaces as a line change. MDX is not evaluated — custom components appear as literal tags instead of rendering — so treat MDX files as source-view comparisons and ignore the preview pane.